А что сейчас точно известно про AX 7?

[Vasiliy Petrovich]

странно, что не было awesome

[ax_mct]

Цитата:

Сообщение от Vasiliy Petrovich

странно, что не было awesome

Было два раза 0:45 и 1:50.

[ax_mct]

Цитата:

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

Господа, релиз ещё не скоро, участники ТАР-программы по подпиской, ваши предложения о революционности продукта с точки зрения разработки несколько завышены

Вопрос. Сможет ли типичный AX программист ("X++ - родной, .NET- уже не так пугает как раньше"), по сути "Visual Basic" программист, создавать в AX7 законченные решения в HTML5 (HTML + JavaScript + CSS)?

Цитата:

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

.. создавать в AX7 законченные решения в HTML5 (HTML + JavaScript + CSS)?

А сможет ли программист в 12 их создавать?
Следующий вопрос а зачем?

[kashperuk]

Цитата:

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

Вопрос. Сможет ли типичный AX программист ("X++ - родной, .NET- уже не так пугает как раньше"), по сути "Visual Basic" программист, создавать в AX7 законченные решения в HTML5 (HTML + JavaScript + CSS)?

Да что ж Вы никак с этим HTML5 не успокоетесь?
Еще раз повторяю - для Х++ девелопера технологии на которые собственно построен интерфейс полностью абстрогированы, то есть не зная ничего о HTML5, JavaScript, CSS, я могу делать все, что мне нужно для создания полноценных решений в АХ

[gl00mie]

Цитата:

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

Да что ж Вы никак с этим HTML5 не успокоетесь?
Еще раз повторяю - для Х++ девелопера технологии на которые собственно построен интерфейс полностью абстрогированы, то есть не зная ничего о HTML5, JavaScript, CSS, я могу делать все, что мне нужно для создания полноценных решений в АХ

О, да!.. Закон Дырявых Абстракций (23 марта 2000):

Цитата:

Все нетривиальные абстракции дырявы. Закон дырявых абстракций означает, к сожалению, что абстракции не так сильно упрощают нашу жизнь, как хотелось бы.
При обучении программистов ASP.NET было бы здорово сказать: мол, дважды кликните мышом на штучку, а затем пишите код, который должен отрабатываться на сервере, когда пользователь кликнет на эту штучку. И правда, ASP.NET абстрагирует разницу между написанием кода HTML для отработки нажатия на гиперссылку (<a>) и кода для отработки нажатия на рисованную клавишу. Проблема: разработчикам ASP.NET пришлось скрыть тот факт, что в HTML нету способа отсылать форму из гиперлинка. Они обходят это, генерируя несколько строчек на JavaScript и добавляя к гиперлинку функцию onclick. Но эта абстракция дырява. Если пользователь отключит JavaScript, то приложение на ASP.NET не будет правильно работать; и если программист не знает, что именно абстрагировалось ASP.NET'ом, он не поймёт, в чём там дело. Из-за закона дырявых абстракций вот что получается: придумает кто-нибудь чудесный новый генератор кода, с которым у программиста работа наконец-то станет эффективной, а ему и говорят: "Сперва научись делать это руками, а потом уж пользуйся генератором, чтобы сэкономить время". Генераторы кода, абстрагирующие разработку кусков кода, так же дырявы, как и все прочие абстракции. А единственный компетентный способ залатать эти дыры - выучить, как работают абстракции, и какие подробности они скрывают. Итак, абстракции экономят наше рабочее время, но не экономят учебное время.
Отсюда парадоксальное следствие: в то время как инструментарий программиста забирается на всё более высокие уровни сложности со всё более развитыми абстракциями, подготовить высококвалифицированного программиста становится всё труднее.
Десять лет назад можно было мечтать, что на сегодняшний день новые компьютерные концепции облегчат труд программиста. И правда: созданные за эти годы абстракции позволяют работать с проектами на порядки более сложными, чем десять или пятнадцать лет назад, типа программирования GUI и сетевого программирования. Но хотя замечательные инструменты, вроде современных объектных языков визуальных форм, позволяют сделать много и очень быстро, вдруг в один злосчастный день приходится искать течь в абстракции, и на это уходит пара недель. А когда вам нужно найти себе программиста в основном на Вижуал Бэйсике, совершенно недостаточно нанять программиста только на Вижуал Бэйсике, потому что каждый раз, когда абстракции Бэйсика потекут, он не сможет сделать ни шага.

Закон дырявых абстракций крепко держит нас за штаны.

[Владимир Максимов]

Цитата:

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

О, да!.. Закон Дырявых Абстракций (23 марта 2000):

Это уже обсуждалось (15.06.2012)

Нужна ли теоретическая подготовка при программировании в Axapta?

Цитата:

Сообщение от Владимир Максимов

Здесь Джоэль явно не договаривает. Точнее, он опускает "совершенно очевидные" вещи. Очевидные для него.

Ну, вот нашли Вы дырку в абстракции. И что Вы дальше будете делать? А ничего! Вы находитесь не на том "уровне" чтобы исправить эту дырку. Вы можете ее только обойти или смириться с ее существованием. Дырка допущена на этапе разработки ядра FrameWork куда доступа программисту просто нет.

А Джоэль, если я правильно понимаю, находится как раз на том уровне, на котором он может исправить эту дырку. Т.е. на уровне разработки этого самого ядра FrameWork. Именно для него подобные знания необходимы. Но вовсе не для поиска этих самых дыр, а просто как инструмент с которым он и работает.

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

Знание конкретной причины возникновения дыры в абстракции сильно повышает "Чувство Собственного Величия" (ЧСВ) однако никак (от слова "совсем") не влияют на написание программного кода.

Например, применительно к приведенной цитате из статьи Джоэля надо просто помнить правило: если приложение сделано на ASP.Net, то отключать JavaScript - нельзя. Все! И совершенно не важно почему этого делать нельзя. Т.е. не имеет значения, что там что-то на JavaScript написано. Просто "нельзя". Ни о каких "дырках в абстракциях" знать не надо.

[gl00mie]

Цитата:

Сообщение от Владимир Максимов

Это уже обсуждалось Программисты Axapta работают не на том уровне абстракции, чтобы наличие "дырки в абстракции" как-то повлияло на сам факт программирования.

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

Цитата:

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

у нас работа завершена тогда когда ее принял заказчик, а не тогда когда ее сделал программист

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

Цитата:

Сообщение от Владимир Максимов

Даже зная о наличии такой дырки программист никак не сможет ее исправить. Только обойти... Причем обойти именно на уровне Axapta, а не на уровне возникновения этой дырки. Ну и смысл искать эти дыры?

Я свои аргументы уже приводил: вкратце, по-моему, чтобы даже обойти проблему (не то, что решить), ее сначала надо диагностировать. К сожалению, шаманские ритуалы вида "тормозит Exists Join? делаем Inner Join" пока разработаны не для всех встречающихся ситуаций.

Цитата:

Сообщение от Владимир Максимов

Применительно к приведенной цитате из статьи Джоэля надо просто помнить правило: если приложение сделано на ASP.Net, то отключать JavaScript - нельзя. Все! Ни о каких "дырках в абстракциях" знать не надо.

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

[Владимир Максимов]

Цитата:

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

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

Предположим, Вы сделали проект на ASP.net. Пользователь на своем компе отключил JavaScript и пишет Вам: приложение не работает. Ваши действия?

[gl00mie]

Обсуждение взаимоотношения с дырявыми абстракциями я предлагаю вести в другой ветке, например, в уже упомянутой Нужна ли теоретическая подготовка при программировании в Axapta?

[ax_mct]

Цитата:

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

Да что ж Вы никак с этим HTML5 не успокоетесь?
Еще раз повторяю - для Х++ девелопера технологии на которые собственно построен интерфейс полностью абстрогированы, то есть не зная ничего о HTML5, JavaScript, CSS, я могу делать все, что мне нужно для создания полноценных решений в АХ

Спасибо за информацию.

Насчет полной цены как раз и волнуюсь. Web он такой, не любит desktop программистов с мышкой. Да и есть глупая надежда что Microsoft станет немного ближе к Web-реальности, уже 15 лет жду.

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

А с абстрагированием штука такая: сложное - просто, а простое - сложно.
Что толку что AX (SharePoint) EP такой вот весь из себя мощный, пользователям web-интерфейсов мощи не нужны.

P.S. Если новый Front-End будет отделен и независим от Back-End логики, то тогда это абстракция. Когда отдельно можно работать с этими слоями.
А если программист отделен от Front-End, без полного контроля над ним, то это не абстракция, а вполне конкретный такой большой бубен

[belugin]

Цитата:

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

Спасибо за информацию.

Насчет полной цены как раз и волнуюсь. Web он такой, не любит desktop программистов с мышкой.

Возможно, публичный веб и такой, а на аксапте у нас не вебсайт, а ERP с вебмордой. К нему другие требования. Это раз. Во-вторых за прошедшие годы веб стал совсем другой. JS уже JITят и прочее.

Цитата:

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

Кодогенерация, после которой надо править руками - отстой. Не отстой кодогенерация с настраиваемыми правилами.

Цитата:

А если программист отделен от Front-End, без полного контроля над ним, то это не абстракция, а вполне конкретный такой большой бубен

Как часто вам приходилось использовать winapi при модифицировании аксапты? Мне вот только для хобби-проектов типа tabax. Да и то, львиную долю сделал Andyd.

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

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

[ax_mct]

Цитата:

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

Возможно, публичный веб и такой, а на аксапте у нас не вебсайт, а ERP с вебмордой. К нему другие требования. Это раз. Во-вторых за прошедшие годы веб стал совсем другой. JS уже JITят и прочее.
...
Может проще заказчика убедить работать с квадратными окнами, нежели делать треугольные.

Мы можем понимать компромиссы, но Пользователь - нет. Более того, по своему уже многолетнему опыту разработки в AX EP (типа AX вебморда) смею сказать что "корпоративный" пользователь намного более "капризен" чем обычный пользователь публичного web-сайта.

Требования по скорости, удобству, внешнему виду (layout etc) UI всегда вагон и маленькая тележка. Не скажешь "а что вы хотели, это вам же не desktop и даже не web, это Intranet/Extranet (а что вы хотели от ERP с вебмордой)!"
Вместо этого все позы камасутры, просто потому что если по миссионерски, то у тебя не будет работы так как клиент либо откажется от AX либо от (EP)программирования в AX вообще.

Web не так сильно и изменился. Скорость выполнения JavaScript (JIT) в браузере это ничто по сравнению с обычной для Microsoft отправкой всей web-страницы на сервер и с размером этой самой страницы. Я не знаю как будет, насколько асинхронно и насколько web, но знаю ожидания и капризы пользователей.

[ax_mct]

В том же EP наряду с требованиями обеспечить "Excel" скорость на web-гридах (двух-секундные задержки типа нервируют пользователей) и автоматического изменения фокуса (типа workflow для скорости введения и чтобы без мышки и по горячим клавишам) пользователь все время хочет массу простых вещи типа изменения стилей на уровне контролов и расположения контролов на отдельной странице.

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

А почему это "долго и дорого и все равно некрасиво"? Потому что платформа и фреймворки нам "в помощь". Речь не идет о том эта помощь нам не нужна, речь о том что это инструменты которые служат нам (помогая обходить проблемы), а не мы служим этим инструментам (как их обойти так как проблема в них).

[ax_mct]

http://diginomica.com/2015/03/19/mic.../#.VagwrhNViko

-Dynamics AX 7 under wraps

Dynamics AX 7, which will come later in the year. This has a “completely reimagined” user interface based on HTML5 and will have the same look-and-feel as the forthcoming Office 16 release.

--Christian Pedersen, general manager of Dynamics Marketing

This release has very strong ties from a data model and business logic perspective with the previous release, but it brings new innovation together in a business solutions context.

The thing you will see shining loud and clear is the user experience. To create a productivity environment that is more like Office.

We’re going to keep the data model and the business logic the same between AX 2012 R3 and AX 7 to keep the upgrade simple.

Yes there are cosmetic changes but you also get a move to an HTML 5 based user experience. You’ll have a user experience with a lot less clicks — a much more productive environment ( вот это интересно, доброго здоровья MS маркетингу, на вас вся надежда ) to work in.

[AP-1055D]

Цитата:

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

Мы можем понимать компромиссы, но Пользователь - нет. Более того, по своему уже многолетнему опыту разработки в AX EP (типа AX вебморда) смею сказать что "корпоративный" пользователь намного более "капризен" чем обычный пользователь публичного web-сайта.

Мой опыт говорит об обратном: корпоративного пользователя можно заставить работать в любой какашке, в любом дерьме какое только можно представить себе, а публичный будет выбирать из того, что ему более приятно, удобнее и так далее. Посмотрите на интерфейс того же SAP или Baan (в Infor, конечно, получше). AX выбирают не за красоту интерфейса или отзывчивость веб-портала. Если вообще "выбирают".

[AP-1055D]

Цитата:

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

Web не так сильно и изменился. Скорость выполнения JavaScript (JIT) в браузере это ничто по сравнению с обычной для Microsoft отправкой всей web-страницы на сервер и с размером этой самой страницы. Я не знаю как будет, насколько асинхронно и насколько web, но знаю ожидания и капризы пользователей.

Web изменился очень сильно. EP, действительно, не настолько быстр, но это потому что использует устаревшую технологию, основанную на идеи WinForms. Но возьмите тот же ASP.Net MVC, ReactJS и отзывчивость интерфейса будет быстрой, не намного медленнее для ввода данных чем на десктоп.

[EVGL]

Цитата:

Сообщение от AP-1055D

Мой опыт говорит об обратном: корпоративного пользователя можно заставить работать в любой какашке, в любом дерьме какое только можно представить себе, а публичный будет выбирать из того, что ему более приятно, удобнее и так далее. Посмотрите на интерфейс того же SAP или Baan (в Infor, конечно, получше). AX выбирают не за красоту интерфейса или отзывчивость веб-портала. Если вообще "выбирают".

Поддерживаю! Истину глаголишь.

[gl00mie]

Цитата:

Сообщение от AP-1055D

Мой опыт говорит об обратном: корпоративного пользователя можно заставить работать в любой какашке, в любом дерьме какое только можно представить себе. Посмотрите на интерфейс того же SAP или Baan.

Уточните, пожалуйста, на чем именно основан ваш опыт в данном случае:

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

В первых двух случаях, может, вы и правы, потому что конечный пользователь обычно видит UI тогда, когда уже решение принято, лицензии закуплены, модификация реализована, зарплата начислена, и деваться пользователю особо некуда - разве что пытаться жалобно ныть своему начальству, мол, пусть сделают поудобнее хотя бы это и вон то.
В случае же заказных доработок я лично чаще встречался с ситуациями, когда заказчик либо изначально придумывает такой вид и поведение UI, которые совершенно не вписываются в стандарт и штатные "кодогенераторы", либо уже в ходе пользовательского тестирования начинает придумывать шашечки и рюшечки, разработка которых по времени с лихвой перекрывает трудозатраты на бизнес-логику. И аргумент у заказчика при этом очень мощный: не сделаете, как мы хотим, - не подпишем акт, соотв., не оплатим работу. В таких ситуациях зачастую требуются серьезные навыки переговорщика для убеждения заказчика в том, что его хотелки - дикий нестандарт, отступление от Best Practices, разрушение целостности user experience, и что "лучше безобразно, но единообразно". Покуда вы каким-то образом не договорились на условия time & materials, заказчик плевать хотел на ограничения стандарта и "кодогенераторов", а также на трудоемкость реализации шашечек и рюшечек. Вы оценили трудоемкость разработки во столько-то часов, заказчик отжал часть из них ("а че так много? тут делать-то нечего, простенькая форма"), а затем уже в эту фиксированную оценку трудоемкости нужно впихнуть хотелки касаемо UI.

[Ivanhoe]

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