|
09.07.2015, 15:39 | #1 |
Участник
|
Цитата:
Согласен с kashperuk по поваду MorphX - тот же зверь, только в студии. В общем и целом Х++ никто не отменял, так что без работы не останетесь.
__________________
AxAssist 2012 - Productivity Tool for Dynamics AX 2012/2009/4.0/3.0 |
|
09.07.2015, 11:57 | #2 |
Участник
|
То есть, если я правильно понимаю, при разработке форм не будет HTML и прочего? Не знаю, мне лично больше импонирует идея разделения на backend- и frontend-разработчиков. Backend-разработчики занимаются реализацией бизнес-логики, интеграцией, frontend разрабатывают отчёты, делают формы, какие-то не сложные вещи типа импорта и тому подобного. В таком случае бэки сосредотачиваются на ядре, бизнес-логике, а фронты на внешних вещах. С моей точки зрения, такое разделение может быть дешевле для компании. Если сейчас на проект нужны два разработчика, то от них требуется знание и фронта и бэка (в том понимании в каком они есть сейчас.) То есть разработчик совмещает две роли в одной, и ему приходится кроме реализации бизнес-логики заниматься интерфейсными-дизайнерскими вещами. А так можно будет взять одно разработчика с хорошим знанием ядра, функциональности, бизнеса закачика, а на фронт найти более дешёвого фронт-разработчика.
|
|
09.07.2015, 14:40 | #3 |
Участник
|
Цитата:
Сообщение от AP-1055D
) То есть разработчик совмещает две роли в одной, и ему приходится кроме реализации бизнес-логики заниматься интерфейсными-дизайнерскими вещами. А так можно будет взять одно разработчика с хорошим знанием ядра, функциональности, бизнеса закачика, а на фронт найти более дешёвого фронт-разработчика.
|
|
09.07.2015, 13:17 | #4 |
Участник
|
И лучше разделять задачи между разработчиками (одним очень не нравится разрабатывать отчёты и создавать лукапы/формы, другим, наоборот, такие задачи могут быть по вкусу), более ясно/точно/мотивированнее разделять уровень зарплаты.
Понятно, что и сейчас на проекте в команде бывают как сильные программисты (те кто хорошо знают особенности ядра, существующую функциональность) так и новички/стажёры/начинающие. Им часто дают задачи по отчётам и так далее. И иногда получается так, что кроме этих задач и не дают более сложные (по очень разным причинам, не только потому, что разработчик не тянет). Вот и получается, что вроде бы занимаешься аксаптой давно, а по факту сложных вещей и не делал. А кому-то и не хочется погружаться в сложную бизнес-логику. В общем, на собеседовании можно было бы с гордостью говорить, что я специалист по frontend! |
|
09.07.2015, 15:41 | #5 |
Участник
|
Peter работает в compiler team - под 6 там остались только багфиксы, наверное
|
|
15.07.2015, 00:15 | #6 |
Lean Six Sigma
|
Господа, релиз ещё не скоро, участники ТАР-программы по подпиской, ваши предложения о революционности продукта с точки зрения разработки несколько завышены
|
|
16.07.2015, 00:48 | #7 |
Banned
|
Вопрос. Сможет ли типичный AX программист ("X++ - родной, .NET- уже не так пугает как раньше"), по сути "Visual Basic" программист, создавать в AX7 законченные решения в HTML5 (HTML + JavaScript + CSS)?
|
|
16.07.2015, 10:21 | #8 |
Гость
|
|
|
16.07.2015, 11:47 | #9 |
Участник
|
Цитата:
Еще раз повторяю - для Х++ девелопера технологии на которые собственно построен интерфейс полностью абстрогированы, то есть не зная ничего о HTML5, JavaScript, CSS, я могу делать все, что мне нужно для создания полноценных решений в АХ |
|
16.07.2015, 12:46 | #10 |
Участник
|
Цитата:
Сообщение от kashperuk
Да что ж Вы никак с этим HTML5 не успокоетесь?
Еще раз повторяю - для Х++ девелопера технологии на которые собственно построен интерфейс полностью абстрогированы, то есть не зная ничего о HTML5, JavaScript, CSS, я могу делать все, что мне нужно для создания полноценных решений в АХ Цитата:
Все нетривиальные абстракции дырявы. Закон дырявых абстракций означает, к сожалению, что абстракции не так сильно упрощают нашу жизнь, как хотелось бы.
При обучении программистов ASP.NET было бы здорово сказать: мол, дважды кликните мышом на штучку, а затем пишите код, который должен отрабатываться на сервере, когда пользователь кликнет на эту штучку. И правда, ASP.NET абстрагирует разницу между написанием кода HTML для отработки нажатия на гиперссылку (<a>) и кода для отработки нажатия на рисованную клавишу. Проблема: разработчикам ASP.NET пришлось скрыть тот факт, что в HTML нету способа отсылать форму из гиперлинка. Они обходят это, генерируя несколько строчек на JavaScript и добавляя к гиперлинку функцию onclick. Но эта абстракция дырява. Если пользователь отключит JavaScript, то приложение на ASP.NET не будет правильно работать; и если программист не знает, что именно абстрагировалось ASP.NET'ом, он не поймёт, в чём там дело. Из-за закона дырявых абстракций вот что получается: придумает кто-нибудь чудесный новый генератор кода, с которым у программиста работа наконец-то станет эффективной, а ему и говорят: "Сперва научись делать это руками, а потом уж пользуйся генератором, чтобы сэкономить время". Генераторы кода, абстрагирующие разработку кусков кода, так же дырявы, как и все прочие абстракции. А единственный компетентный способ залатать эти дыры - выучить, как работают абстракции, и какие подробности они скрывают. Итак, абстракции экономят наше рабочее время, но не экономят учебное время. Отсюда парадоксальное следствие: в то время как инструментарий программиста забирается на всё более высокие уровни сложности со всё более развитыми абстракциями, подготовить высококвалифицированного программиста становится всё труднее. Десять лет назад можно было мечтать, что на сегодняшний день новые компьютерные концепции облегчат труд программиста. И правда: созданные за эти годы абстракции позволяют работать с проектами на порядки более сложными, чем десять или пятнадцать лет назад, типа программирования GUI и сетевого программирования. Но хотя замечательные инструменты, вроде современных объектных языков визуальных форм, позволяют сделать много и очень быстро, вдруг в один злосчастный день приходится искать течь в абстракции, и на это уходит пара недель. А когда вам нужно найти себе программиста в основном на Вижуал Бэйсике, совершенно недостаточно нанять программиста только на Вижуал Бэйсике, потому что каждый раз, когда абстракции Бэйсика потекут, он не сможет сделать ни шага. Закон дырявых абстракций крепко держит нас за штаны. |
|
|
За это сообщение автора поблагодарили: Morpheus (3), ax_mct (3). |
16.07.2015, 15:15 | #11 |
Участник
|
Цитата:
Сообщение от gl00mie
О, да!.. Закон Дырявых Абстракций (23 марта 2000):
Нужна ли теоретическая подготовка при программировании в Axapta? Цитата:
Сообщение от Владимир Максимов
Здесь Джоэль явно не договаривает. Точнее, он опускает "совершенно очевидные" вещи. Очевидные для него.
Ну, вот нашли Вы дырку в абстракции. И что Вы дальше будете делать? А ничего! Вы находитесь не на том "уровне" чтобы исправить эту дырку. Вы можете ее только обойти или смириться с ее существованием. Дырка допущена на этапе разработки ядра FrameWork куда доступа программисту просто нет. А Джоэль, если я правильно понимаю, находится как раз на том уровне, на котором он может исправить эту дырку. Т.е. на уровне разработки этого самого ядра FrameWork. Именно для него подобные знания необходимы. Но вовсе не для поиска этих самых дыр, а просто как инструмент с которым он и работает. На языке программистов это уже давно называется либо баг, либо фича. В зависимости от критичности найденной дырки. Знание конкретной причины возникновения дыры в абстракции сильно повышает "Чувство Собственного Величия" (ЧСВ) однако никак (от слова "совсем") не влияют на написание программного кода. Например, применительно к приведенной цитате из статьи Джоэля надо просто помнить правило: если приложение сделано на ASP.Net, то отключать JavaScript - нельзя. Все! И совершенно не важно почему этого делать нельзя. Т.е. не имеет значения, что там что-то на JavaScript написано. Просто "нельзя". Ни о каких "дырках в абстракциях" знать не надо.
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... Последний раз редактировалось Владимир Максимов; 16.07.2015 в 16:02. |
|
17.07.2015, 13:51 | #12 |
Участник
|
Собственно автор сам указывает чего будет стоить отказ даже от дырявых абстракций.
Цитата:
И правда: созданные за эти годы абстракции позволяют работать с проектами на порядки более сложными, чем десять или пятнадцать лет назад, типа программирования GUI и сетевого программирования. Но хотя замечательные инструменты, вроде современных объектных языков визуальных форм, позволяют сделать много и очень быстро, вдруг в один злосчастный день приходится искать течь в абстракции, и на это уходит пара недель.
|
|
16.07.2015, 20:57 | #13 |
Banned
|
Цитата:
Сообщение от kashperuk
Да что ж Вы никак с этим HTML5 не успокоетесь?
Еще раз повторяю - для Х++ девелопера технологии на которые собственно построен интерфейс полностью абстрогированы, то есть не зная ничего о HTML5, JavaScript, CSS, я могу делать все, что мне нужно для создания полноценных решений в АХ Насчет полной цены как раз и волнуюсь. Web он такой, не любит desktop программистов с мышкой. Да и есть глупая надежда что Microsoft станет немного ближе к Web-реальности, уже 15 лет жду. Было бы здорово если бы новый интерфейс предусматривал стандартную возможность полного контроля программиста над рендерингом помимо "автоматической" генерации. То есть некий wizard, но потом все в твоих руках. А с абстрагированием штука такая: сложное - просто, а простое - сложно. Что толку что AX (SharePoint) EP такой вот весь из себя мощный, пользователям web-интерфейсов мощи не нужны. P.S. Если новый Front-End будет отделен и независим от Back-End логики, то тогда это абстракция. Когда отдельно можно работать с этими слоями. А если программист отделен от Front-End, без полного контроля над ним, то это не абстракция, а вполне конкретный такой большой бубен Последний раз редактировалось ax_mct; 16.07.2015 в 21:14. Причина: P.S. |
|
16.07.2015, 21:26 | #14 |
Участник
|
Цитата:
Цитата:
Было бы здорово если бы новый интерфейс предусматривал стандартную возможность полного контроля программиста над рендерингом помимо "автоматической" генерации. То есть некий wizard, но потом все в твоих руках.
Цитата:
А если программист отделен от Front-End, без полного контроля над ним, то это не абстракция, а вполне конкретный такой большой бубен
Вообще, если программисту захотелось залезть в дырку, то надо сначала спросить: делает ли он это ради фана или есть причина серьезная. А если есть серьезная, то представляет ли он себе то количество вопросов, которыми надо задаться когда слезаешь с платформы и идешь своими ногами (поддержка браузеров, обновления, безопасность и т.д.). Может проще заказчика убедить работать с квадратными окнами, нежели делать треугольные. |
|
|
За это сообщение автора поблагодарили: EVGL (1). |
15.07.2015, 01:59 | #15 |
Участник
|
|
|
15.07.2015, 14:16 | #16 |
Участник
|
|
|
|
За это сообщение автора поблагодарили: EVGL (1), kashperuk (1). |
15.07.2015, 21:06 | #17 |
Участник
|
странно, что не было awesome
|
|
16.07.2015, 00:39 | #18 |
Banned
|
|
|
16.07.2015, 16:27 | #19 |
Участник
|
Обсуждение взаимоотношения с дырявыми абстракциями я предлагаю вести в другой ветке, например, в уже упомянутой Нужна ли теоретическая подготовка при программировании в Axapta?
|
|
|
За это сообщение автора поблагодарили: mazzy (2). |
17.07.2015, 00:47 | #20 |
Banned
|
В том же EP наряду с требованиями обеспечить "Excel" скорость на web-гридах (двух-секундные задержки типа нервируют пользователей) и автоматического изменения фокуса (типа workflow для скорости введения и чтобы без мышки и по горячим клавишам) пользователь все время хочет массу простых вещи типа изменения стилей на уровне контролов и расположения контролов на отдельной странице.
Для того чтобы сделать это в текущей ERP вебморде нужно быть циркачем и уметь своей ногой почесать за своим ухом. Не вопрос, только долго и дорого и все равно некрасиво. Для поддержки вообще счастье разбираться во всех этих workarounds (танцах с бубном). А почему это "долго и дорого и все равно некрасиво"? Потому что платформа и фреймворки нам "в помощь". Речь не идет о том эта помощь нам не нужна, речь о том что это инструменты которые служат нам (помогая обходить проблемы), а не мы служим этим инструментам (как их обойти так как проблема в них). |
|