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

[Logger]

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

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

Цитата:

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

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

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

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

[belugin]

Цитата:

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

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

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

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

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

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

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

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

[ax_mct]

Цитата:

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

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

Согласен. Если подумать то CLR это подобная JVM вещь как process VM, и там и там запускается P-code (MSIL и Java Bytecode). И там и там компиляция. Но тут вопрос момента этой компиляции и тех самых сочетаний нюансов.

CLR требует компиляцию всего кода сразу и до. То есть взяли копировать Java/JVM но так и не поняли ее суть.

JVM компилирует частями и по потребности (в общем случае). Что позволяет оптимизацию при исполнении и более быструю разработку.

Та же Аксапта использовала JVM и такую "интерпретационную" компиляцию по частям что давало нам множество преимуществ в разработке. C необходимостью полной сборки MorphX был бы невозможен. А без MorphX это не 21 век.

P.S.
AppStore что сейчас обсуждается тоже душу не греет потому как скопирован опять таки с потерей сути. Действительно хочется увидеть клиента D365FO устанавливающего AppStore по кнопке. Это скорее анекдот.

[belugin]

Цитата:

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

CLR требует компиляцию всего кода сразу и до. То есть взяли копировать Java/JVM но так и не поняли ее суть.

Вы имеете ввиду компиляцию из исходного кода в промежуточный или из промежуточного в машинный?

Не могли бы вы привести ссылку для подтверждения своего утверджения?

Compilation by the JIT Compiler
JIT compilation converts MSIL to native code on demand at application run time, when the contents of an assembly are loaded and executed.

[ax_mct]

Цитата:

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

Вы имеете ввиду компиляцию из исходного кода в промежуточный или из промежуточного в машинный?

Не могли бы вы привести ссылку для подтверждения своего утверджения?

Compilation by the JIT Compiler
JIT compilation converts MSIL to native code on demand at application run time, when the contents of an assembly are loaded and executed.

Думаю что из промежуточного в машинный.
Промежуточный это P-code в X++, CIL в .NET, Bytecode (.class) в Java. Это файлы полученные из исходного кода и которые используются VM для перевода в машинный код (ngen и прочие не общие вещи не расматриваем).

Действительно получается что все упирается в реализацию JIT.
В Java их далеко не одна. Самый общий это HotSpot
https://ru.wikipedia.org/wiki/HotSpot
который сочетает и компилятор и интерпретатор.

Oracle HotSpot это больше 80% рынка JVM.

https://plumbr.io/blog/java/java-version-and-vendor-data-analyzed-2017-edition

Oracle HotSpot использует интерпретацию по умолчанию, и только потом компиляцию часто используемых методов.

Цитата:

HotSpot VM defaults to interpreting Java byte code. It compiles (JIT compilation) methods that runtime profiling determines to be "hot", that is, the methods that are executed for a predetermined number of times. JIT compliers are either client or server compilers.

https://docs.oracle.com/javase/9/jro...n.htm#JRHMG117

В CLR возможностей использования интерпретации в JIT - нет совсем.
А она таки для программистов удобнее и мы ее потеряли с D365FO.

[belugin]

Цитата:

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

Действительно получается что все упирается в реализацию JIT.

А чем код железного процессора так отличается от кода виртуальной машины что это в корне запрещает hotswapping? (кстати, VS поддерживает edit and continue для C++)

И еще, какие ограничения есть на hotswapping у JVM из коробки и зачем нужны всякие чудестные другие штуки, которые находятся по запросу "java hotswapping" (типа JRebel).

Лично мое мнение что для продакшена концептуально лучше blue-green deployment - это позволяет получить гарантию, что код относится к одной какой-то версии. Что вы про это думаете?

Для разработки есть edit and continue с ограничениями (что на JVM, что на .NET).

Еще интересно про "интерпретаторы" - про тот же PHP сложилось впечатление, там нет никакого хотсваппинга (т.е. время жизни всего в типичном случае - один запрос) и легкость обновления достигается именно за счет этого, нет?

[ax_mct]

Цитата:

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

А чем код железного процессора так отличается от кода виртуальной машины что это в корне запрещает hotswapping? (кстати, VS поддерживает edit and continue для C++)

Думаю что это ограничения OS, в частности Windows. Регистрация в реестре и невозможность удалить файл если он "используется".
VM это сама себе OS и что хочет то и может себе позволить. При этом там где интерпретация это явно легче.

Цитата:

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

И еще, какие ограничения есть на hotswapping у JVM из коробки и зачем нужны всякие чудестные другие штуки, которые находятся по запросу "java hotswapping" (типа JRebel).

JRebel не просто заменяет код метода, а позволяет менять сигнатуру, добавлять и удалять методы.
А это не просто бросить jar, а как-то обновлять все ссылки в работающей VM. Это реально круто.

Цитата:

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

Лично мое мнение что для продакшена концептуально лучше blue-green deployment - это позволяет получить гарантию, что код относится к одной какой-то версии. Что вы про это думаете?

Для разработки есть edit and continue с ограничениями (что на JVM, что на .NET).

Подмена приложения (blue-green deployment ) в большинстве случаев все равно требует downtime пусть и значительно уменьшенный. А главное опять же нехилый DevOps и особенно с DB.

Есть еще отключаемый Compile on Save, но тут если в Java мы компилируем исходник .java в байткод .class на уровне класса, то как я понимаю VS это делает на уровне проекта.

Цитата:

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

Еще интересно про "интерпретаторы" - про тот же PHP сложилось впечатление, там нет никакого хотсваппинга (т.е. время жизни всего в типичном случае - один запрос) и легкость обновления достигается именно за счет этого, нет?

Так и есть. Помимо этого дает еще и неубиваемость в отличие от того же ASP.NET.
PHP наиболее отвечает stateless природе web.
Кэширование (Vanish http://php.net/manual/en/book.varnish.php etc) еще надо сливать все же.
Типа удалить из некой папки кэш.

А как мы можем blue-green deployment в D365FO? Это может MS без downtime?
Тут ведь помимо downtime и вопрос срочности.
Я на практике где сомневаюсь обрамляю код параметром DB. Типа список галок на некой форме для отключения недавно добавленного функционала пусть даже это просто кусок кода. Потому как даже в AX2012 страшно жить.

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