Первые впечатления от программирования в D365FO

[belugin]

Zitat:

Zitat von trud

Visual Basic .NET имеет такой же рейтинг как C#
Как такое вообще может быть?
что и кто интересно на нем разрабатывает. т.е. сколько я народу не знаю, никогда даже не слышал, сайт по поиску работы тоже 0 возвращает

Там методика описана. Вот еще индексы популярности:
https://en.wikipedia.org/wiki/Measur...larity#Indices

Во втором сверху у C# тоже 5

[AlexeyS]

смотря что и как считать, вот, например, интересная аналитика от stackoverflow

[belugin]

4 место https://insights.stackoverflow.com/s...ming-languages

[ax_mct]

Zitat:

Zitat von belugin

Как вы думаете, операионная система под которой вы сейчас сидите это большой проект? На каком языке она написана?

https://www.tiobe.com/tiobe-index/ - пятого места мало?

Zitat:

Zitat von belugin

4 место https://insights.stackoverflow.com/s...ming-languages

Наш (enterprise) большой проект это прежде всего прикладной проект где одна их характеристик - большая изменчивость. Скриптовые и интерпретируемые языки намного удобнее для программистов так где надо работать над требованиями.

В X++ все было RAD именно в силу интерпретации. Вся эта DLLность D365FO она не нужна в процессе разработки и билда.

Будущее C# подразумевалось как завоевание рынка Java на момент создания платформы .NET.
Чего не случилось за эти 15-20 лет. Замах был на рубль, а по сути произошел просто переход тех кто программировал под WIndows на VB и C++ MFC и пр. То есть обновление уже существующего своего рынка, в пределах уже лояльной к MS массы и не более того.

Вопрос в том насколько программирование в D365FO является современным программированием остается открытым Нормальные хипстеры не компилируют, это устарело лет на 30.

[belugin]

Zitat:

Zitat von ax_mct

Наш (enterprise) большой проект это прежде всего прикладной проект где одна их характеристик - большая изменчивость. Скриптовые и интерпретируемые языки намного удобнее для программистов так где надо работать над требованиями.

Никаких интерпретируемых языков больше нет. Все компилируется. Джаваскрипт компилируется внутре. Для больших проектов к нему присобачивают cтатическую типизацию к php тоже прикручивают.

Zitat:

В X++ все было RAD именно в силу интерпретации. Вся эта DLLность D365FO она не нужна в процессе разработки и билда.
Вопрос в том насколько программирование в D365FO является современным программированием остается открытым Нормальные хипстеры не компилируют, это устарело лет на 30.

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

PS. WebAssembly and the Death of JavaScript

[ax_mct]

Zitat:

Zitat von belugin

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

Ага. Все четко.
Только если у нас есть X++ в AX2012 и только потом папка с CIL как отдельная компиляция вне процесса разработки,
и есть D365FO где нам надо билдить в CIL при каждом изменении в процессе разработки,
то разница есть
несмотря на то что мы тоже как бы компилируем X++ (в P-code).

Почему же нам монолитность AppSuite не мешает в AX2012?
При том что "интерпретируемых языков больше нет".

[belugin]

Zitat:

Zitat von ax_mct

Ага. Все четко.
Только если у нас есть X++ в AX2012 и только потом папка с CIL как отдельная компиляция вне процесса разработки,

Я тут писал пкрекодировщик для http://erpkb.info и вижу в процессе набора что-то не то. Оказалось, что тесты покраснели - я включил live unit testing и он мне покрасил в красный те строчки, которые выполнялись во время теста который я завалил. Интересное ощущение.

Еще когда году в 2003 начал писать на Eclipse, в начале было некоторое непонимание - там компиляция шла фоном и инициировалась по кнопке сохранить.

Zitat:

Почему же нам монолитность AppSuite не мешает в AX2012?
При том что "интерпретируемых языков больше нет".

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

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

Zitat:

Будущее C# подразумевалось как завоевание рынка Java на момент создания платформы .NET.

Насколько я помню, сначала MS делал свою Java - причем очень тесно интегрированную в винду. Например, на ней очень удобно было делать COM-компоненты. Потом на этой почые они поругались с SUN, а потом возник .NET.

На кроссплатформенный рынок .NET стал выходить сравнительно недавно, после покупки Xamarin и разработки .NET Core.

Глянул в википедию - там написано, что это была часть .NET Strategy типа плана по захвату интернета?

[Logger]

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

А по сути Ax_mct трижды прав:

Zitat:

Наш (enterprise) большой проект это прежде всего прикладной проект где одна их характеристик - большая изменчивость. Скриптовые и интерпретируемые языки намного удобнее для программистов так где надо работать над требованиями.

X++ в 2009-й ведет себя почти как скриптовый язык. Благодаря этому можно накатывать по живой базе. Т.е. можно быстро обновлять приложение не выгоняя всех юзеров и для обновления не надо стопить надолго аос. Изменчивость - наше все.

А с введение CIL в 2012-й всего-то добавили "маленькую" проблему - большой монолитный AppSuite. И все поломали.

Ну а дальше еще хуже.

[ax_mct]

Zitat:

Zitat von belugin

Я тут писал пкрекодировщик для http://erpkb.info
...

Сайт вроде бы на Lua и PHP. Неужели писал в VS перекодировщик для перехода на C#?
И каков результат?

Zitat:

Zitat von belugin

Еще когда году в 2003 начал писать на Eclipse, в начале было некоторое непонимание - там компиляция шла фоном и инициировалась по кнопке сохранить.

Я за Eclipse сел в 2004 на крупном Java проекте, после того как будучи MCSD.NET образца 2003 просто не смог найти достойную работу в Питере по С#. Тогда еще будущее С# не успело наступить

Zitat:

Zitat von belugin

В Ax2012 есть проблемы, но другие. Попробуйте, например, не перекомпилировать
наследники

Это вопрос привычки делать "Compile forward". Маленькая проблема на самом деле.

Zitat:

Zitat von belugin

типа плана по захвату интернета?

Пока успешны только планы по обматыванию паутиной тех кто уже во всем этом.

Программирование в D365FO это TFS, TFS это платная подписка на Visual Studio.
Один из клиентов поставил условие обязательного использования TFS.
Минимум это $539/year за пользователя. Как я понимаю без учета ирландского VAT.
https://www.visualstudio.com/vs/pricing/

Что отметили изначально в теме это нехилый DevOps что для TFS что для D365FO.
В новых реалиях D365FO выгодней не программировать а делать DevOps.
Кстати тот парень что купил аксаптовикипедию позиционирует себя именно как не программист, а DevOps специалист, он рубит фишку на сегодня. Постараюсь с ним увидеться, грамотный у него подход, интересно.
https://www.agilecadence.com/consultancy/

То есть по теме, одно из основных изменений это появление роли и сама роль DevOps.

А то что скрипты победили DLL в мировой гонке это наверное другая тема.
В сравнении же программирования в MorphX и в VS - понятно же что VS это шаг назад в 90e, если сравнивать MorphX который вполне соответствовал 21 веку.

[trud]

Zitat:

Zitat von ax_mct

В сравнении же программирования в MorphX и в VS - понятно же что VS это шаг назад в 90e, если сравнивать MorphX который вполне соответствовал 21 веку.

Так то оно так конечно, но если подняться на уровень выше, то уже доступно 118 решений(причем каждое содержит описание БП, технологии загрузки данных, бесконфликтный код для новой версии и прочее). Т.е. такого в принципе не было на 2009, 2012, здесь явный прогресс.

https://appsource.microsoft.com/en-u...rations&page=1

[belugin]

Zitat:

Zitat von ax_mct

Сайт вроде бы на Lua и PHP.

На PHP

Zitat:

Неужели писал в VS перекодировщик для перехода на C#?
И каков результат?

Отдельный консольный перекодировщик из формата wackowiki в формат dokuwiki.

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

Zitat:

Я за Eclipse сел в 2004 на крупном Java проекте, после того как будучи MCSD.NET образца 2003 просто не смог найти достойную работу в Питере по С#. Тогда еще будущее С# не успело наступить

Поинт в том, что Java - тоже компилируемый язык.

[belugin]

Zitat:

Zitat von Logger

X++ в 2009-й ведет себя почти как скриптовый язык. Благодаря этому можно накатывать по живой базе. Т.е. можно быстро обновлять приложение не выгоняя всех юзеров и для обновления не надо стопить надолго аос. Изменчивость - наше все.

Это проблема не компилируемости как таковой ИМХО а конкретного сочетания технологий.

В принципе, есть технология для hotswapping в .NET и она даже используется в Ax2012 . FED, правда, говорил, что глючит.

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

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

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

Еще вполне возможно что в других технологиях с хотсвоппингом лучше. Например edit and continue в вижуал студии для C# работает с большими ограничениями - в Java, говорят, их меньше.

[Ivanhoe]

Zitat:

Zitat von trud

Так то оно так конечно, но если подняться на уровень выше, то уже доступно 118 решений(причем каждое содержит описание БП, технологии загрузки данных, бесконфликтный код для новой версии и прочее). Т.е. такого в принципе не было на 2009, 2012, здесь явный прогресс.

https://appsource.microsoft.com/en-u...rations&page=1

Что не мешало существовать рынку решений и на предыдущих версиях.

И я очень сомневаюсь в реальной работе таких решений в Dyn365FO без нормального мерджинга и тестирования (ну окромя совсем модулей сбоку).

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

[trud]

Zitat:

Zitat von Ivanhoe

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

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

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

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

[fed]

Zitat:

Zitat von trud

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

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

Я в этом AppSource наткнулся на решение для текстиля от Porini, с которым я имел несчастье сталкиваться. Решение датировано где-то началом 2017ого года (По крайней мере на AppSource), что наводит на мысль что более свежие версии недоступны. Шансы что разработчик сможет это глюкалово поднять на extensions вероятно несколько ниже ноля. Кроме того - помниться году в 2016ом мы пытались откомпилить приложение с best practice и у нас, помнится, были проблемы с переполнением списка нарушения таковых. Я НИКОГДА не поверю что это решение можно довести. Только выкинуть и переписать с ноля. (Но для этого нужна команда, которая имеет опыт внедрения Ax, а не самописки перенесенной с Delphi на X++).
Так что мой диагноз - AppSource - такой же маркетинговый баллшит как и прошлые микрософтовские попытки создать рынок вертикальных решений.

[trud]

Zitat:

Zitat von fed

Решение датировано где-то началом 2017ого года (По крайней мере на AppSource), что наводит на мысль что более свежие версии недоступны.

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

Zitat:

The CAR must be submitted to Microsoft six weeks after the fall and spring releases.

https://docs.microsoft.com/en-us/dyn...-lcs-solutions

[fed]

Zitat:

Zitat von trud

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

https://docs.microsoft.com/en-us/dyn...-lcs-solutions

Вопрос еще в том - насколько эти требования соблюдаются. Есть шансы что тут возможны варианты. Ну и как я сказал - если Microsoft эту глючную самописку не постеснялся выложить и заапрувить, то я этот AppSource не могу всерьез воспринимать...

[Ivanhoe]

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

[trud]

Zitat:

Zitat von Ivanhoe

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

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

[fed]

Zitat:

Zitat von trud

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

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