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

[Alex_KD]

Цитата:

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

интересно, кто они, где они сейчас, и чем занимаются
Peter Villadsen не один из них, случаем?

Судя по тому что это имя светится на одной из презенташек для AX7, чел занимается 7кой.

Согласен с kashperuk по поваду MorphX - тот же зверь, только в студии.
В общем и целом Х++ никто не отменял, так что без работы не останетесь.

[AP-1055D]

То есть, если я правильно понимаю, при разработке форм не будет HTML и прочего? Не знаю, мне лично больше импонирует идея разделения на backend- и frontend-разработчиков. Backend-разработчики занимаются реализацией бизнес-логики, интеграцией, frontend разрабатывают отчёты, делают формы, какие-то не сложные вещи типа импорта и тому подобного. В таком случае бэки сосредотачиваются на ядре, бизнес-логике, а фронты на внешних вещах. С моей точки зрения, такое разделение может быть дешевле для компании. Если сейчас на проект нужны два разработчика, то от них требуется знание и фронта и бэка (в том понимании в каком они есть сейчас.) То есть разработчик совмещает две роли в одной, и ему приходится кроме реализации бизнес-логики заниматься интерфейсными-дизайнерскими вещами. А так можно будет взять одно разработчика с хорошим знанием ядра, функциональности, бизнеса закачика, а на фронт найти более дешёвого фронт-разработчика.

[belugin]

Цитата:

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

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

Как-то по моему опыту задачи связанные с дизайном встречаются довольно редко в разработке на ax. Обычно типа "добавить закладку с тремя полями и кнопку" или шаблонные формы.

[AP-1055D]

И лучше разделять задачи между разработчиками (одним очень не нравится разрабатывать отчёты и создавать лукапы/формы, другим, наоборот, такие задачи могут быть по вкусу), более ясно/точно/мотивированнее разделять уровень зарплаты.

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

[belugin]

Peter работает в compiler team - под 6 там остались только багфиксы, наверное

[Ned]

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

[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 написано. Просто "нельзя". Ни о каких "дырках в абстракциях" знать не надо.

[brahma]

Цитата:

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

О, да!..

Собственно автор сам указывает чего будет стоить отказ даже от дырявых абстракций.

Цитата:

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

Кажется очевидным выбор между потерей 2 недель на поиск дырки и возможностью вообще делать такого уровня проекты.

[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.

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

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

[kashperuk]

Вот что думают зарубежные партнеры о новом релизе

https://youtu.be/On_KXJRKkVY

[Morpheus]

Цитата:

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

Вот что думают зарубежные партнеры о новом релизе

https://youtu.be/On_KXJRKkVY

Я впечатлен до глубины души. Надеюсь, что маркетинговые материалы будут более содержательными чем "flexible", "fantastic" и "exciting" а AX 7 не постигнет судьба виндовс смартфонов.

[Vasiliy Petrovich]

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

[ax_mct]

Цитата:

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

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

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

[gl00mie]

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

[ax_mct]

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

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

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