Why is the approach taken to de-integrate everything in Ax?

[EVGL]

**** выделено отсюда AXDevCenter Headlines: See the Future of X++ and .NET *****

Хочется процитировать один комментарий:

Цитата:

Why is the approach taken to de-integrate everything in Ax? It's strongest point is the fact that you have a single tool-set for everything and now the direction seems to be moving away from that. When you rely on other tools (eg SSRS) you're effectively introducing a new system and interface, and there will always be a disconnect between the two. Is it just to incorporate as many technologies as possible as opposed to actually improving developer productivity? I am honestly, yet to hear a solid technical argument for this approach as opposed to marketing based 'xxx is the future'. The day-to-day issues that come up with installing all of these systems (SSRS, Sharepoint, EP) and the problems that occur from differing versions/service packs/etc are constant and very frustrating. And at this point (V2009) the tools and integration are not as solid or reliable as one would hope. In terms of 'dropping X++ reports' - I shudder to think what the SSRS implementation of something like financial statements or the highly procedural/configurable reports would be like.

I'm generally interested in the overall approach and reasoning as this is my day-to-day work.

Могу подписаться под каждым словом. Если Microsoft'у интересно, почему так плохо продается ролевой портал, то этот комментарий дает один из ответов.

[mazzy]

Цитата:

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

Если Microsoft'у интересно, почему так плохо продается ролевой портал, то этот комментарий дает один из ответов.

Ну...
Дело не в "single tool-set", а "new system and interface"
В том же Навике тоже есть новые отчеты и они тоже сделаны на SSRS.
Но сделана действительно "бесшовная" интеграция, пользователь не замечает что он в другом приложении - продолжает пользоваться своими любимыми и привычными фильтрами, окно похоже на окно Навижина и т.п...

(картинки напоминают на детскую игру "найди знакомый предмет на картинке". Попробуйте найти интерфейс SSRS на картинках )




диалоговое окно для ввода параметров и фильтров


см. http://navision.mazzy.ru/lib/nav2009-reports/

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

[AlGol]

Цитата:

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

В том же Навике тоже есть новые отчеты и они тоже сделаны на SSRS.
Но сделана действительно "бесшовная" интеграция, пользователь не замечает....

А разработчик тоже не заметит этой бесшовной интеграции, когда ему закажут "практически такой же отчет как уже есть в системе"?

[mazzy]

Цитата:

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

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

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

Цитата:

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

А разработчик тоже не заметит этой бесшовной интеграции, когда ему закажут "практически такой же отчет как уже есть в системе"?

Заметит конечно. В первую очередь: ему надо знать по крайней мере две среды разработки.

Я же ссылку приводил http://navision.mazzy.ru/lib/nav2009-reports/
Почитайте как оно со стороны разработчика.

Разработчикам Навика проще. В Навике нет такой офигительной штуки, как расширенные типы и relations на этих типах. Поэтому разработчикам Навика проще перейти на VS - и там, и там вручную поля и связи ставить надо.

Разработчикам Аксапты - сложнее. Меня, например, просто наизнанку выворачивает от того, что VS не подхватывает связи, метки, ширину поля и прочее из EDT. Нне могу заставить заниматься такими вещами вручную. Очень надеюсь, что подобное получит развитие...

[kashperuk]

Цитата:

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

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

Процитирую EVGL из 1ого поста - "Могу подписаться под каждым словом"

Цитата:

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

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

Гы

[mazzy]

Цитата:

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

Могу подписаться под каждым словом. Если Microsoft'у интересно, почему так плохо продается ролевой портал, то этот комментарий дает один из ответов.

Мое мнение такое:
Майкрософт использует Great Plains в качестве базовой системы для развития своих технологий. GP технологически, функционально и интерфейсно слабее даже Навижина, не говоря уже об Аксапте.

В результате то, что для GP выглядит как Wow-эффект, для Аксапты и Навижина выглядит регрессом.

1. Так навигационные списки с отбором по одному полю из списка - явный регрес для Аксапты и в большой степени для Навижина.
2. В GP отсутствовал модуль CRM - сделали интеграцию с MS CRM для всех систем. Для пользователей GP - ура-ажиотаж и новый функционал. Для пользователей Аксапты и Навижина сплошной гемор, ад, треш и угар, поскольку в них есть свой модуль CRM (который Майкрософту пришлось передвинуть в Advanced-лицензию) и что теперь делать - совершенно непонятно.

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

Поэтому видимо торопиться не стоит.
"Еще 1832 ведра, и золотой ключик у нас в кармане" (С)

[fed]

Цитата:

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

Мое мнение такое:
Майкрософт использует Great Plains в качестве базовой системы для развития своих технологий. GP технологически, функционально и интерфейсно слабее даже Навижина, не говоря уже об Аксапте.

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

На мой взгляд - бесполезно искать за происходящим какой-то рациональный контекст. Почитай того же Майка Эренберга. Просто кто-то неплохо пиарит себя внутри Майкрософт рассказывая про ролевой интерфейс, разработку управляемую моделями, интеграцию с .net, облачные вычисления и том как это сильно повышает динамичность бизнеса (c). С потребностями рынка это не связано, но получить пару повышений по службе за счет этого - очень даже можно...
P.S. Кстати почитал биографию Эренберга. Пишут: "As CTO at Marcam, Ehrenberg drove the development of the first ERP product for Windows NT, deeply architected for the Microsoft platform. " Дальше ищем в Гугле про Marcam. "In 1994 Marcam began developing it’s next generation product for platforms beyond IBM’s AS/400. This product, known as Protean, was written using Object Oriented Programming. In May of 1999, facing the downturn from the Y2K crash, and many technology challenges stemming from the Proteon project, Marcam threw in the towel and sold out to Invensys, Plc."

В общем - у чувака большой опыт в разработке ERP с использованием объектно-ориентированных технологий. Один продукт этих технологий уже не выдержал

[glibs]

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

[virtuoso]

Цитата:

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

Под вопросом идея тонкого клиента (работа по модему, пусть с тормозами).

Поясните, пожалуйста, свою мысль: что не так с тонким клиентом?

[fed]

Цитата:

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

Поясните, пожалуйста, свою мысль: что не так с тонким клиентом?

В старину (до выхода 4ой версии) официальные требования к каналу между AOS и клиентом были такими:
64Kbit на 10 клиентов, задержки в канале - 50ms. (конечно это не означало что один клиент сможет работать на канале шириной 6.4KBit, просто из 10 клиентов в данный момент времени с системой обычно работало 2-3 и на них хватало этих 64Кбит).
На практике - эти требования конечно были малость занижены. Для комфортной работы надо было 128Кбит на 10 пользователей и 20ms задержки в канале.

С переходом Аксапты под крыло микрософт требования к ширине канала возросли до 100MBit, а к задержке в канале - до "менее 5ms".

[glibs]

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

[glibs]

Цитата:

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

...
многие уникальные идеи не только не получили развития, но и были затоптаны
...

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

С учетом описанной выше оговорки у меня еще сложилось впечатление, что в то время как многое в Аксапте рискует исчезнуть во имя нового общего там интерфейса... некоторые технологии успешно взял на вооружение 1С.

Впрочем, инсайдерской информацией я не обладаю. Посмотрим, что будет дальше.

Я слышал отзывы нескольких клиентов, перешедших с 3.0 на 5.0. Общее мнение было: "Бе". Ax32.exe утяжеляется. Требования к ресурсам растут. Много нового функционала пишется так, что на тонких каналах будет тормозить (сама манера формы рисовать имеется в виду).

[gl00mie]

По поводу интеграции - мне кажется, на эту тему более чем исчерпывающе выразились тут: Peter Villadsen and Gustavo Plancarte: X++ to MSIL

Цитата:

Люди часто повторяют: надо стоять на плечах гигантов, и, думаю, в вашей студии это звучало не раз, но я чувствую, что это именно то, что мы должны делать. Нам не следует самим нести все затраты, связанные с поддержкой и развитием всей инфраструктуры, когда есть такие отличные вещи, как .NET, и Visual Studio, и LINQ.

Просто изначально в ядре Аксапты было реализовано много такого, что является совершенно самостоятельными продуктами у того же Ms, и тут возникает вопрос: либо дублировать разработку одних и тех же вещей, явно проигрывая с точки зрения возможностей в случае "изобретения велосипедов" для Аксапты, либо заменить встроенные в нее "велосипеды" интеграцией с самостоятельными продуктами, службами, технологиями. Среди таких "велосипедов" можно отметить:

• собственный протокол AOCP, заменный на RPC;
• собственный механизм аутентификации пользователей и шифрования их паролей, заменный на Windows-аутентификацию;
• собственный механизм управления всеми настроенными на машине AOS'ами (к слову, дырявый с точки зрения безопасности), замененный на стандартные виндовые сервисы;
• собственный формат БД для хранения приложения, замененный в 6-й версии на БД Ms SQL Server;
• собственный движок справки, замененный на HtmlHelp;
• собственный "движок" для корпоративного портала, замененный на Sharepoint;
• собственная среда разработки, часть функций которой плавно переходит в Visual Studio;
• собственный интерпретатор собственного же байт-кода, которые экспериментально заменяется на IL и CLR;
• собственный движок отчетов, местами противоречивый с точки зрения архитектуры и в прошлом явно неоднократно приспосабливаемый под какие-то частные задачи, а теперь постепенно уступающий место SSRS

В общем, когда разработку ведет сторонняя контора, не контролирующая платформу и технологии, которые используются ее продуктом, то логично сделать продукт в значительной степени самодостаточным, но когда разработку начинает вести компания, которая разрабатывает и платформу, и СУБД, и все сопутствующие технологии, то логично не дублировать все эти возможности в отдельно взятом продукте, а интегрировать его с тем, что уже есть и работает.
А по поводу утяжеления клиента и повышения требований к каналам... можно вспомнить того же Джоэла Спольски:

Цитата:

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

[fed]

Вспоминается старый анекдот про то как Хрущев съездил в Англию и по итогам визита решил перевести СССР на левостороннее движение. Ну и для начала, в качестве эксперимента, попробовали запустить 100 автомобилей на Садовое Кольцо по левой стороне.

Просто не очень понятно - какой смысл ЧАСТЬ среды разработки мигрировать на Visual Studio и вообще микрософтовские технологии, если в принципе не понятно как на VS и .net отмигрировать такую фундаментальную технологию как технология слоев.
Вот если уважаемые любители стоять на плечах гигантов объяснят мне как они собираются ее мигрировать - я перестану бухтеть.
Какой вот смысл делать все эти AOD-browser для Visual Studio, переносить отчеты на SSRS и выносить отчеты на WF (от которого даже знакомые .netовцы стонут и ругаются неприлично), если не видно способа миграции всего приложения и всей среды на новые технологии ?

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

[belugin]

Цитата:

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

Просто не очень понятно - какой смысл ЧАСТЬ среды разработки мигрировать на Visual Studio и вообще микрософтовские технологии, если в принципе не понятно как на VS и .net отмигрировать такую фундаментальную технологию как технология слоев.

Ну лично я предпочту немножко попереключаться между окнами, чем рисовать отчет в глюковатом MorphXном редакторе.

Цитата:

Вот если уважаемые любители стоять на плечах гигантов объяснят мне как они собираются ее мигрировать - я перестану бухтеть.
Какой вот смысл делать все эти AOD-browser для Visual Studio, переносить отчеты на SSRS и выносить отчеты на WF (от которого даже знакомые .netовцы стонут и ругаются неприлично), если не видно способа миграции всего приложения и всей среды на новые технологии ?

Возможно, тем кто делает видно, а не тебе. И тем, кто участвует в TAP.

Цитата:

Кстати - меня вот как-то мало волнует экономия разработчиков на разработке ядра, если это не сопровождается падением стоимости одной лицензии.

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

Цитата:

больше тратить денег на дополнительные работы на внедрении, связанные с той самой интеграцией ?

Пример, пожалуйста.

[fed]

Цитата:

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

Возможно, тем кто делает видно, а не тебе. И тем, кто участвует в TAP.

Дык возникает вопрос - если они технологию слоев в VS и .net поддержали, то почему они об этом не пишут во всех блогах и Channel 9, а пишут про какие-то примочки к AOD и улучшения в компиляторе X++ ?

Цитата:

ты думаешь лиуензии продаются по себестоимости?

А какая мне разница - насколько сильно сэкономил вендор ? Вот если конечная цена для меня ТОЖЕ упала - вот тогда я готов радоваться что вендор сэкономил на разработке отдельного сборщика мусора или редактора отчетов.
Вообще - забавно. В классической экономической теории, после того как товар выходит из нишевого рынка на массовый, его цена должна СИЛЬНО упасть, поскольку падает доля затрат на R&D в единице товара. (Вспомни цены LCD-мониторов 10 лет назад и сейчас). Однако, в случае Аксапты, эта цена почему-то выросла в ДВА раза.Как раз недавно знакомые, которые на старой схеме лицензирования остались, считали во сколько им лицензия на одного пользователя в 2001 году обошлась и сколько она же стоит теперь.

Цитата:

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

Меньше глюков ? Я две недели назад как с одного проекта. Дык вот там программисты из лучших побуждений сделали так, чтобы закупку нельзя было разнести пока она не пройдет большую цепочку утверждений. Однако выяснилось, что из за уникальной глючности ядра workflow в Аксапте, этот самый workflow не может пройти быстрее чем за 4-5 часов. После почти месяца общения с саппортом, удалось решить эту проблему, только закомментировав большую часть проверок security и прав доступа в workflow. Похоже что разработчики не тестировали свой код при числе пользователей больше 50 и числе групп больше 1.

Цитата:

Пример, пожалуйста.

Вот тут mazzy жалуется на то что ему приходиться держать одного человека на X++ и одного на Visual Studio axtools: Navigating the AX Application Explorer in Visual Studio
Не думаю что ему человек на C# обошелся бесплатно
Ну и тут еще glibs чуть выше написал.

[belugin]

Цитата:

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

выносить отчеты на WF (от которого даже знакомые .netовцы стонут и ругаются неприлично),

Кстати, спроси их, что они думают про WF 4

[fed]

Цитата:

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

Кстати, спроси их, что они думают про WF 4

Дык может не надо было Аксаптовский workflow релизить ДО выхода WF4 ?
Вот внедрили бы лучше Аксапту внутри MBD и тренировались бы на кошках

[glibs]

Цитата:

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

...
собственный протокол AOCP, заменный на RPC;
...

Вроде писали, что не заменили, а завернули одно внутрь другого.

Цитата:

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

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

Кто пытался завести десятки и сотни тысяч пользователей на портале через AD очень в восторге от этой идеи.

Цитата:

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

...
собственный формат БД для хранения приложения, замененный в 6-й версии на БД Ms SQL Server;
...

А чем это лучше если не секрет? В VS тоже исходный код в реляционной СУБД живет?

Цитата:

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

...
собственный движок справки, замененный на HtmlHelp;
...

И справки не стало. А старый движок был проще. И это было единое хранилище, а не кучка файлов. И слои были, кажется. И вызов пунктов меню.

Цитата:

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

...
собственный "движок" для корпоративного портала, замененный на Sharepoint;
...

Развертывание стало трудоемким. Польза в чем? Может производительность подросла, но не слышал примеров от практиков, к сожалению. Не факт, что это был единственный путь.

Цитата:

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

...
когда разработку ведет сторонняя контора
...

Да, Аксапта много потеряла когда попала в лапы Микрософту.

Цитата:

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

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

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

[belugin]

Имхо проблема не в том, что, части технологии Ax заменяются частями стека Microsoft, а в том, что кое-где они недостаточно тесно интегрированы.

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

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

Проблема в том, что пока он не использует настолько же плотно модель данных AX, как родной движок. Но с другой стороны, сейчас никто не заставляет его использовать.

Вот если бы вы владели компанией по разработке ПО, вы бы предпочли рарабатывать 5 движков отчетов или 1? Почему тогда не нравится два модуля ОС