Как ощущения от Axapta 2012 R2 ?

[MikeR]

Если открываешь связанное окно из интерфейса, то оно открывается в фоне, и надо дополнительно мышкой его оттуда вытаскивать. Причем озвучивал это еще осенью на презентации, обещали исправить, на дворе R2 и уже лето, а проблема осталась.
Надо всего то дописать setFocus на каждом новом открываемом окне, это сложно?

[kashperuk]

Zitat:

Zitat von mazzy

Если все равно нужно осваивать новую систему, то почему именно Аксапту? Есть и другие системы.

Согласно "magic quadrant" от Гартнер, Microsoft Dynamics AX - один из лидеров на рынке ERP. Это разве не достаточная причина?

Zitat:

Zitat von mnt_dx

А были опросы на эту тему?

Ну, как минимум, на кажом Convergence, Tech Ready, т.д., расспрашивают
Ну и помимо этого много собирают с существующих клиентов/партнеров, но больше думаю с тех, которые учавствовали или учавствуют в TAP программе.

[EVGL]

Зависит от того, кто ездит на конференции. Люди, как правило, одни и те же, из эшелона продавцов и руководителей. Там все довольны, продается хорошо, в PowerPoint смотрится еще лучше.

А в принципе, нытья автора темы по поводу интерфейса и "отсутствия функционала" не разделяю, человек не видит идеи Workflow, которая заложена за интерфейсом. Проблемы все, скорее, в мелочах и внутри, чего стоит только имя товара отредактировать. Еще можно видеть, как разработчики кое-где решили закончить работу посередине и пошли получать премию. См. пример \Services\InventItemService. Ничего не бросается в глаза?

[Vadim Korepin]

Женя прав с точки зрения того, кто посещает - а там чем красивее картинка, тем действительно лучше

Если вставить свои 5 копеек, то функционал действительно стал лучше, причем местами значительно и кое-где сгладилась нелогичность той же АХ2009 - где явно закладывали задел на будущее. Например, тот же MDM логичен и удобен - если не нравится вариант отдельного заведения - просто сведите процедуру до минимума.

А чего не хватает и что очень ждал от 2012R2 так это скорости - всё-таки работала бы она ещё шустрее цены бы ей не было.

P.S.
Да и ещё долбанный DMF, руки оторвать тому, кто его выпустил в таком виде на рынок.

[macklakov]

Zitat:

Zitat von kashperuk

Согласно "magic quadrant" от Гартнер, Microsoft Dynamics AX - один из лидеров на рынке ERP. Это разве не достаточная причина?

Давайте не будем путать нашу личную шерсть с государственной. Есть рынок труда, есть рынок ERP.
Если уж пришлось разобраться с .Net, Sharepoint и SSRS, SSAS то возникает вопрос, а зачем еще и с AX разбираться? Зарплаты сходные, а количество заморочек в разы меньше. Ведь аксапщику все равно приходится глюках этих продуктов разбираться, а вот специалисту по Sharepoint или BI вовсе не обязательно заморачиваться всеми этими глюками ядра AX, глюками интеграции, глюками фукнционала.
Смысл наращивать экспертизу в глюках? Это не делает программиста сильнее. Это не является инвестицией в будущее. Это не внесешь в резюме. Глюки сегодня есть, а завтра их починили или заменили на новые.

[belugin]

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

[macklakov]

Zitat:

Zitat von belugin

подавляющее большинство кода осталось как было - вот такое мое впечатление.

Нетронутого кода почти не осталось. Вроде класс тот же, а сигнатура другая. Таблица вроде есть, а название уже другое или часть полей куда-то снесена. Но это ладно. Система должна развиваться. Все понятно.
Хуже глюки. Даже базовые инструменты погнуты злой рукой.
Хочу по коду поск по коду запустить, ctrl+V не работает. Браузер таблиц вроде еще есть, но без нормальной фильтрации и по большинству полей переход к основной таблице не работает. На перекрестные полагаться теперь нельзя. Отчеты временами очень удивляют. Но портал еще больше удивления вызывает. Работать с VS только на сервере нормально получается. Жить можно, но как же усложняет работу!
Нет, Microsoft молодцы. Подвинчивают, подкручивают на ходу. Отзывы активно собирают. Но есть такое ощущение, что слегка поторопились. Несколько больше обычного глюков зарелизили.

[sukhanchik]

Zitat:

Zitat von belugin

подавляющее большинство кода осталось как было - вот такое мое впечатление.

Хех... Наличие кода не говорит о сохранении идеологии работы в системе. Кстати, код может быть и нерабочим

Пример 1. Формы ListPage. Раньше открываешь справочник клиентов и в нем можно сразу править. Теперь идеология сменилась - сначала открывается список (CustTableListPage), а затем можно провалиться в форму деталей. Не беря в расчет выполненные изменения над формой деталей - можно сказать, что для правки записи о клиенте - необходимо теперь из формы списка провалиться в форму деталей, тогда как в предыдущих версиях системы можно было править данные сразу в одной форме.

Что было сделано: Добавлена новая форма и вызов из меню был перенаправлен на новую форму. Старый код остался как был - он не менялся. Но идеология работы изменилась.

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

Пример 3, разработческий. Раньше я мог рассчитывать на 1,5-2 часовую компиляцию системы. На то, что за ночь у меня полностью обновятся перекрестные ссылки. По крайней мере на имеющемся у меня сервере, который является вполне рабочим. Теперь - не могу. Значит я должен как-то перестраивать идеологию работы с кодом, исходя из того, что теперь с утра я не получу свежую информацию о перекрестных ссылках.
Что было сделано: Было добавлено много кода. Понятное дело, что если объем кода увеличить в 2 раза (как минимум), то и построение ссылок и компиляция будут как минимум в 2 раза дольше работать. Но когда это "дольше" превысит некоторый критический порог по времени (ночь) - то для меня, как для разработчика - этот факт создаст задачу по продумыванию идеологии смены подхода (не рассчитывать теперь на свежие перекрестные ссылки с утра). Хотя код остался старым .

[belugin]

Zitat:

Zitat von macklakov

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

Если смотреть по методам, то может быть; если по строчкам, то осталось много. Просто изменены несколько ключевых абстракций которые используется везде. Можно еще сравнить количество таблиц, по которым есть data upgrade и общее количество таблиц

[gl00mie]

Zitat:

Zitat von belugin

Если смотреть по методам, то может быть; если по строчкам, то осталось много.

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

Zitat:

Zitat von belugin

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

[belugin]

Zitat:

Zitat von gl00mie

Дык, это разработчикам функционала или их менеджерам интересно строчки считать,

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

Если вы предлагаете другую метрику (например, трудоемкость), то можно сравнить и ее. Например, насколько проще перетащить решение на 2012 чем на SAP.

Мысль не в том, считать или не считать строчки, а сравнивать то, что изменилось с тем, что не изменилось (а не просто удивляться как много изменилось в абсолютном значении или по сравнению с переходом Ax4 -> Ax2009).

[Vadik]

Zitat:

Zitat von sukhanchik

Пример 3, разработческий. Раньше я мог рассчитывать на 1,5-2 часовую компиляцию системы. На то, что за ночь у меня полностью обновятся перекрестные ссылки. По крайней мере на имеющемся у меня сервере, который является вполне рабочим. Теперь - не могу. Значит я должен как-то перестраивать идеологию работы с кодом, исходя из того, что теперь с утра я не получу свежую информацию о перекрестных ссылках

Не расскажете, что у вас за проект \ команда такие, что поменяв "о" малое (0.01 - 0.10 %) от общего числа объектов в системе за день, ну позарез нужно обновить перекрестные ссылки к следующему утру ?

Zitat:

Раньше я мог рассчитывать на 1,5-2 часовую компиляцию системы

Теперь можете рассчитывать на 3 (что в принципе при заявленном для RTM разрастании кода раза в 3 плюс все локализации включая индийскую в одном слое весьма неплохо) - эта разница в 1 час принципиальна ?

[ice]

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

[Logger]

Zitat:

Zitat von sukhanchik

Пример 3, разработческий. Раньше я мог рассчитывать на 1,5-2 часовую компиляцию системы. На то, что за ночь у меня полностью обновятся перекрестные ссылки. По крайней мере на имеющемся у меня сервере, который является вполне рабочим. Теперь - не могу. Значит я должен как-то перестраивать идеологию работы с кодом, исходя из того, что теперь с утра я не получу свежую информацию о перекрестных ссылках.
Что было сделано: Было добавлено много кода. Понятное дело, что если объем кода увеличить в 2 раза (как минимум), то и построение ссылок и компиляция будут как минимум в 2 раза дольше работать. Но когда это "дольше" превысит некоторый критический порог по времени (ночь) - то для меня, как для разработчика - этот факт создаст задачу по продумыванию идеологии смены подхода (не рассчитывать теперь на свежие перекрестные ссылки с утра). Хотя код остался старым .

Проблема со скоростью сбора перекрестных ссылок была и в 2009-й. Просто не стояла так остро. Но 6-11 часов на сбор ссылок все равно многовато было.

Меня напрягает другое. Теперь даже собранные перекрестные ссылки не покрывают весь код системы. Как жить дальше ? Как разбираться в новом коде ? Как оценивать риски от внесения изменений в приложение ?

[belugin]

Zitat:

Zitat von Logger

Теперь даже собранные перекрестные ссылки не покрывают весь код системы.

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

[Logger]

Сходу затрудняюсь дать ссылку.
В отзывах на форуме проскакивало что не все в них попадает.
Если это не так, то я только рад.

[sukhanchik]

Zitat:

Zitat von Vadik

Не расскажете, что у вас за проект \ команда такие, что поменяв "о" малое (0.01 - 0.10 %) от общего числа объектов в системе за день, ну позарез нужно обновить перекрестные ссылки к следующему утру ?

Все просто. Когда добавляешь код - так сильно ссылки не нужны. Когда удаляешь код - ссылки ОЧЕНЬ нужны. А дальше - все зависит от того - кто как работает. Легко добавлять код в стандарт. Сложнее чистить "авгиевы конюшни". В т.ч. при переводе "решений" на АХ 2012. Если конечно вести разговор не о тупом переносе кода, а об анализе слабодокументированного функционала и попытке его применения к новым реалиям.

Zitat:

Zitat von Vadik

эта разница в 1 час принципиальна ?

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