AX2009 has been Released

[mazzy]

Цитата:

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

Библиотеку контроллов, сложнее но тоже, в целом, реально. А вот что со словарем данных, расширенными типами, таблицами делать - уже не понятно.

Нормально. Тоже переносится в библиотеку.
Сам AOD - это файл-контейнер. Т.е. названное тобой относится не к ядру, а к системным библиотекам.

Цитата:

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

А если вспомнить про технологию слоев и про то что в CLR уже есть некая своя система версионирования сборок (не очень похожая по идеологии на слои), то уже совсем непонятно становится...

Слои уже меняют

mfp: New Layers in Dynamics AX 2009
mfp: Solving the element ID problem

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

Что делать - вопрос не технический, а концептуально-маркетинговый.

[mazzy]

Цитата:

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

Что делать - вопрос не технический, а концептуально-маркетинговый.

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

но это тоже вопрос концептуально-маркетинговый, а не технический

[slava09]

Насчет RS: хорошо подходит для аналитических отчетов, а вот для регламентированных (счета, нанладные и т.д.) не очень. Это мое мнение.
Если согласны, то в связи с этим вопрос: каким средством делать такие отчеты, если останется только RS?

[mazzy]

Цитата:

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

подходит ... не очень. ...
Если согласны, то в связи с этим вопрос: каким средством делать такие отчеты, если останется только RS?

Согласен - "не очень подходит". Но ведь нельзя сказать, что "очень не подходит".
Поэтому RS

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

Такой способ, конечно, не противоречит Statement of Direction... Но почему-то хочется чуда...

[fed]

Мне вот, кстати, кажется что с точки зрения среды разработки, наиболее интересным вариантом развития Аксапты была бы замена технологии слоев на технологию патчей. То есть - каждая целостная доработка описывается как некий патч, состящий из набора изменений методов, свойств, полей, таблиц и т.п. Для каждого патча прописывается набор зависимостей, то есть список других патчей и, главное, их версий, которые нужны для нормальной работы данного патча. Тогда можно было бы делать настоящие расширения прикладной функциональности и появился бы настоящий рынок ISV.
Вот, собственно, и все чего мне от среды разработки и языка в Аксапте не хватает.
К слову сказать, разработка в ERP, от классической модели разработки, как раз и отличается тем, что мы не пишем функциональность с ноля, а разрабатываем набор модификаций к чужой функциональности. VS изначально ориентирована на классическую модель разработки. Вот поэтому мне и кажется что для ERPшной модели разработки она не очень подходит; Правильнее развивать то что есть в Аксапте, а не пытаться через силу засунуть ее в классическое IDE.

[mazzy]

Цитата:

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

Вот, собственно, и все чего мне от среды разработки и языка в Аксапте не хватает.

А мне не хватает нормального механизма отчетов. C блэкджеком и шлюхами С дрил-дауном и выгрузкой в Эксель

Цитата:

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

К слову сказать, разработка в ERP, от классической модели разработки, как раз и отличается тем, что мы не пишем функциональность с ноля, а разрабатываем набор модификаций к чужой функциональности. VS изначально ориентирована на классическую модель разработки. Вот поэтому мне и кажется что для ERPшной модели разработки она не очень подходит; Правильнее развивать то что есть в Аксапте, а не пытаться через силу засунуть ее в классическое IDE.

Мне кажется, что в этом утверждении что-то не так.
Разработка "с ноля" делается очень редко, даже в классической модели.
Гораздо чаще проект развивается на основании уже существующих библиотек, выпускается новая версия, человек приходит на уже давно ведущийся проект и т.п. По-моему ERPшная модель разработки ничем не отличается от классической.
Можешь объяснишь, почему считаешь, что классическая модель не очень подходит?

[fed]

Цитата:

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

Можешь объяснишь, почему считаешь, что классическая модель не очень подходит?

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

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

Да и кстати поставлять заказчику библиотеку в виде diffа к xpo-файлам было бы странно

[miklenew]

Цитата:

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

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

А мне кажется и выдумывать ничего не надо. Работать надо, а не фантазировать.
Axapt-овцев и так не много. Стажёров мало кто хочет и мало кто умеет воспитывать.
А тут ещё постаянные фантазии. Так скоро вообще ни кто в стажёры не пойдёт.
То одно, то другое, то третье. Спугнём.
Старый анекдот
Кроха сын пришел к отцу программисту
- Папа, а почему солнце встает на востоке и садится на западе?
- Ты проверял?
- Проверял
- Сам проверял?
- Сам проверял
- Долго проверял
- Да сколько себя помню
- Тогда, ради всего святого, ничего не трогай!
Axapta работает, сам проверял, так зачем менять.

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

Угу. Особенно в той же версии и даже не в сервис-паке, а в каком-нибудь хот-фиксе, который посвящен совсем другой тематике...
По рогам и по мозгам им за это...
Но только по-моему это тоже не особенность ERPшного подхода

Цитата:

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

Кстати - как ни странно, аналогичная ситуация есть в Linux.

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

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

[slava09]

Цитата:

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

Согласен - "не очень подходит". Но ведь нельзя сказать, что "очень не подходит".
Поэтому RS

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

Такой способ, конечно, не противоречит Statement of Direction... Но почему-то хочется чуда...

Думаю Excel оптимальный вариант с... как вы там говорили... концептуально-маркетинговой точки зрения

[mazzy]

Цитата:

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

Думаю Excel оптимальный вариант с... как вы там говорили... концептуально-маркетинговой точки зрения

Ни совсем. Если будет Excel, то шансов на появление дрил-дауна обратно в Аксапту - почти никаких

[fed]

Хотел mazzy процитировать но запутался в наших с ним взаимных квотах

Это как раз типичная ERPшная ситуация. Вендору, по каким-то причинам, нужно изменить функционал. Возможно, изменение этого функционала приведет к несовместимости с доработками партнеров и клиентов. При этом, вендор, в общем случае, ничего не знает об этих партнерских и клиентских доработках и оценить масштабы бедствия просто не может.
Если не изобретать велосипед - то что надо было бы, по твоему мнению, делать в подобной ситуации ? Вариант ответа "Правильно программировать", "Думать головой когда программируешь" и т.п. не подходит. Во первых люди вообще склонны ошибатся, во вторых никакие методики не позволяют гарантированно программировать с учетом будущих событий Невозможно разрабатывать программу так, чтобы она гарантирована легко адаптировалась под неизвестные в данный момент будущие изменения функциональности. То есть - конечно мне тоже время от времени попадаются куски кода, за которые их авторам хочется оторвать руки. Но я понимаю, что вполне возможно, что в тот момент когда этот код писался - он не был таким уж кривым...

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

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

[egorych]

А можно немножко конкретный вопрос - работает-ли в 2009 старый портал (от Ax 3) ? Ну то-есть без SharePoint можно его построить ?

[mazzy]

Цитата:

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

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

Ну, почему же ERPшная? Ты почитай хотя бы Страустрапа, как они C++ меняли, что с библиотеками делают. Винда ведь тоже не с нуля пишется. Тоже содержит кучу библиотек, многие из которых используется в доработках другими.

И ничего, более-менее выход найден.

Цитата:

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

Если не изобретать велосипед - то что надо было бы, по твоему мнению, делать в подобной ситуации ?

Сохранят совместимость со старыми. Если возникает что-то новое, то писать рядом стоящую библиотеку, а старую объявлять устаревшей и рекомендовать не использовать... В общем, это уже давно проработанный вопрос, по-моему.

Цитата:

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

Ну и кстати - ситуация с библиотеками не очень подходит в качестве примера.

Хорошо, офис с его функциями и макроязыком, всевозможные шелы от vbscript до javascript...

Цитата:

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

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

Ну, почему же, есть библиотеки и в исходных кодах.
На моей памяти это были всякие TurboVision и OWL. Думаю, что и сейчас такие есть.

Цитата:

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

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

Я просто хочу сказать, что это не особенность для ERP-разработки.

Цитата:

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

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

Ок. Но сначала лучше посмотреть как решают аналогичную проблему другие

[mazzy]

Цитата:

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

А можно немножко конкретный вопрос - работает-ли в 2009 старый портал (от Ax 3) ? Ну то-есть без SharePoint можно его построить ?

Нет.

[fed]

Как-то я довольно редко видел ситуации, при которых кто-то изменял бы исходные тексты TurboVision, OWL или MFC. Равно как и ситуации с изменением исходных текстов интерпретаторов JavaScript или VBA Так что пример не очень удачный.
Подход библиотек как раз работает только в тех случаях, когда их исходный код либо вообще не правится внедренцем, либо правится очень слабо.

[brahma]

Цитата:

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

Сохранят совместимость со старыми. Если возникает что-то новое, то писать рядом стоящую библиотеку, а старую объявлять устаревшей и рекомендовать не использовать... В общем, это уже давно проработанный вопрос, по-моему.

Цитата:

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

Цитата:

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

А можно немножко конкретный вопрос - работает-ли в 2009 старый портал (от Ax 3) ? Ну то-есть без SharePoint можно его построить ?

Нет.

Прикольно.

[mazzy]

Цитата:

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

Прикольно.

От старого портала отказались еще в ax4.0.
По идее, запускаться он на ax4.0 не должен
Совместимость с ax4.0 в ax5.0 формально сохранена. Хотя согласен с тем, что это пример того, как не надо развивать библиотеку. Надо не удалять, а объявлять устаревшей. При этом надо бы полностью сохранять работоспособность старого кода.

[glibs]

Цитата:

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

...
А мне не хватает нормального механизма отчетов. ... С дрил-дауном и выгрузкой в Эксель
...

А RS делает drill-down?

Есть вариант делать в OLAP. МБС делал в запросах в GUI интерфейсе (буржуйский сделал только для ваучеров ГК). Drill-down можно запрограммировать и на портале.

По-моему, было б желание...

[mazzy]

Цитата:

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

А RS делает drill-down?

делает. но не в Аксапту

Цитата:

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

Есть вариант делать в OLAP. МБС делал в запросах в GUI интерфейсе (буржуйский сделал только для ваучеров ГК). Drill-down можно запрограммировать и на портале.

А мне не нравится "можно сделать".
Я хотел бы, чтобы "это уже было реализовано"