mfp: X++ in AX7: Internal keyword

[gl00mie]

Прелестно... особенно с учетом того, что обновления стандартного приложения AX 2012 R3 поставляются мелкими моделями. Способ поставки обновлений изменится, или это - фича сугубо для ISV?

[macklakov]

Цитата:

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

Прелестно... особенно с учетом того, что обновления стандартного приложения AX 2012 R3 поставляются мелкими моделями. Способ поставки обновлений изменится, или это - фича сугубо для ISV?

Да ладно. Исходники ведь останутся видны. Если очень нужно, закомментишь в верхнем слое, всего и делов.

[Stitch_MS]

Цитата:

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

...что обновления стандартного приложения AX 2012 R3 поставляются мелкими моделями. Способ поставки обновлений изменится, или это - фича сугубо для ISV?

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

Т.е. хотя Peter Villadsen не рекомендует использование pre- и post-event handlers, я считаю, что лучше использовать их где только можно, хотя бы на методах, параметры и назначение которых вряд ли изменится в будущем, типа системных xRecord.validateField.

[fed]

Цитата:

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

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

Вообще побывав на Convergence, я все время вспоминал старую шутку насчет "Как мало вы в сущности знаете о добрых феях". Микрософт, похоже что считает что:
1. Партнеры забирают 70-90% бюджета проекта, при этом нихера не делают. В конце концов - ведь внедрение - это только галочки расставить и может печатные формы подправить.
2. Если установить все в облаке - и саму аксапту и их микрософтовский чудо-конфигуратор в LCS -то нужда в партнерах почти отпадет и Микрософт сможет срубить больше бабла на лицензиях.
3. Поскольку обновления буду устанавливаться автоматически, то аксапта не будет иметь номера версии, и все клиенты всегда будут работать на последнем хотфиксе. Ну накрайняк - слегка заплатят каким-нить фрилансерам за апгрейд печатных форм.
.....
5. Profit!

В общем - как мало, в сущности, микрософт знает о добых феях....

P.S. Это я к тому что бесполезно рассуждать о стратегии Микрософта. Это броуновское движение. Вот попробуют они поработать с их новым подходом к рынку и придется им корректировать представления...

[George Nordic]

Цитата:

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

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

Или рынок

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

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

[gl00mie]

Цитата:

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

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

Мне кажется, не все так наивны, как минимум, среди тех, кто уже занимается поддержкой всяких облачных сервисов. К примеру, Eric Brechner (автор Hard Code) еще в 2010-м году писал в There's no place like production:

Цитата:

My current team has separate environments for development, check-in testing, scenario testing, stress testing, cross-division integration, partner integration, certification, and production. That’s eight different environments — and we’re planning to build out a preproduction environment next year.
What kind of fools build out and maintain useless environments? The kind who got burned building enterprise software. Large businesses rely on enterprise software — it’s got to work or they won’t buy it. Once they buy it, they own it. You don’t get to fix enterprise software anytime you want. That’s right, not even with security patches.
Remember, enterprise paychecks depend on having the software run smoothly. Software changes represent risk to an enterprise business. If the software doesn’t work, work well, and continue working well, enterprises businesses aren’t buying it. And they’ll tell you when they are darn well ready to accept a patch.
An entire generation of Microsoft engineers learned the hard way that you can’t release software until the code is fully tested. There are no “retries” in enterprise software.

Но там же он рассуждает о том, что в случае с сервисами всё иначе, и нужно выкатывать изменения в рабочую среду, но просто не для всех клиентов сразу

Цитата:

Let’s recap. There’s no place like production. You need a development environment to run a small set of automated check-in tests, a test environment to run preliminary acceptance and stress testing to help avoid catastrophic failures, and production. Anything more is superfluous.
There’s no place like production. The problem becomes configuring production to permit the testing and certifying of prerelease code. The solution is called “continuous deployment.” The concept is simple: deploy multiple builds to production, and use custom routing to direct traffic as desired. It’s like a source control system for regulating services instead of source files.

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

[mazzy]

Цитата:

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

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

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

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

а вот с этим как-то... посмотрим.

[macklakov]

Цитата:

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

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

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

[macklakov]

Цитата:

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

их микрософтовский чудо-конфигуратор в LCS -то нужда в партнерах почти отпадет и Микрософт сможет срубить больше бабла на лицензиях.

Ага, как раз иду на проект, на котором MS обещался все забабахать с помощью LCS за 3 месяца. 6 месяцев назад, на собеседовании, я сказал что в сказки не верю, чем очень обидел тогдашнюю program manager. До запуска все те же 3 месяца...

[macklakov]

P.S. реально я знаю о ситуации на этом проекте лишь со слов PM. Возможно это были ее личные завышенные ожидания.

[Link]

Цитата:

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

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

Т.е. хотя Peter Villadsen не рекомендует использование pre- и post-event handlers, я считаю, что лучше использовать их где только можно, хотя бы на методах, параметры и назначение которых вряд ли изменится в будущем, типа системных xRecord.validateField.

Мой текущий клиент пользуется в разработке таким подходом. При любой возможности на стандартных и партнерских классах и таблицах для модификаций используют event handlers. Но имхо затраты на разработку выше затрат на апгрейд.
К тому же в 7ке для этого нужно использовать extension methods.