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

[egorych]

Цитата:

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

Утопия! О таких волшебных средах/framework'ах мечтали в свое время разработчики CASE-систем, но все равно оказалось, что без программистов не обойтись...

+100500 !!!
Вспомнить хотя бы MDA для Delphi или что-то похожее для Розы!
ИМХО архитектор 2012 решил наступить на те же грабли, только сильнее!

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

Цитата:

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

Например - понять, почему двигатель может глохнуть на низких оборотах, а знание особенностей АКПП подскажет, что не стоит буксировать оборудованную ей машину.

И как это поможет преодолеть проблему? Цель - беспроблемная езда. Тот факт, что я знаю из-за чего возникает проблема никак не помогает мне ехать.

Цитата:

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

Идеология системы предусматривает активную работу только с текущим, образно говоря, рабочим набором данных:

Да. И в этом ее недостаток.

1. Системное администрирование чрезвычайно усложняется с ростом базы данных. Банально сделать Backup - крайне сложно.
2. Нерациональное использование дискового пространства. Информация уже не нужна, а место занимает.
3. Значительные проблемы при любой модификации структуры базы данных. Вставить/удалить поле - большая проблема
4. Как уже упоминал Vadik, изменение PK таблиц-справочников также будет выполняться очень долго

Ну, отчеты - это отдельный разговор. Ну, не рассчитана Axapta на так любимые в РФ статистические отчеты. Попытка использования стандартных отчетов/классов приводит к глобальному подвешиванию системы на очень длительный срок.

Цитата:

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

Утопия! О таких волшебных средах/framework'ах мечтали в свое время разработчики CASE-систем, но все равно оказалось, что без программистов не обойтись...

Если Вы делаете PK на основании EDT и устанавливаете Relation, то такой пункты меню, как "Перейти к основной таблице" появляется как бы "автоматически". Вы ничего для этого специально не делаете. Вы можете ничего не знать, про факт существования такого пункта меню, но он все равно появится вне зависимости от Вашего знания.

Если Вы этого не делаете, то в случае возникновения необходимости в пункте меню "Перейти к основной таблице" необходимо будет перекрывать методы и писать код. Система "тонко намекает", что Вы делаете что-то не то. Что-то, что идет в разрез с ее идеологией.

Насчет того, что можно обойтись без программистов я вообще ничего не говорил. В конце концов, а кто же будет делать то самое "А", чтобы появилось "Б", "В" и "Г"

Цитата:

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

Надеюсь, этот пассаж про смешение презентационной и безнес-логики был лишь стёбом...

Здесь непонимание с обеих сторон. Вы не поняли о чем я говорил, а я не понял какое отношение Ваш пример имеет к моим словам. О чем шла речь я пояснил чуть выше на примере появления пункта меню.

Цитата:

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

Как минимум можно сообщить разработчику абстракции и получить хорошие шансы на то, что дырка будет им вскоре залатана; если разработчик не будет знать о дыре, очень велика вероятность, что проблема так никуда и не денется.Ну как так... вот, к примеру, падает тот же АОС при выполнении определенного кода, или клиент виснет в каких-то ситуациях, или все работает, но на ровном месте памяти отжирается невообразимо много... Пусть проблема в АОСе/клиенте/виндах/еще ком-то - но это же не значит, что ее не надо пытаться решать или хотя бы пытаться смягчить ее проявления? Деньги-то не за то платят, чтобы руки разводить и говорить "я не на том уровне"

Замечательно. Разбираем по пунктам

1. Нашли дырку в абстракции
2. Сообщили разработчику

Наши дальнейшие действия? Сидим, ждем выхода следующего релиза или фикса? И сколько ждать? А программа не работает! А деньги нам за что платят?

Что делает разработчки в этом случае? Ищет пути обхода. На своем уровне. А вовсе не на уровне дырки в абстракции. Тормозит Exists Join? Делаем Inner Join. Базовый класс сжирает всю память? Используем временные таблицы. И т.д. и и.п.

В результате имеем решение проблемы вообще никак не связанное с осознанием причины "дырки в абстракции". Мы просто знаем, что "Ты туда не ходи. Снег башка попадет" (с). Ну, и протаптываем "обходные пути"

Кроме того, для информирования разработчика вообще-то не нужно знать причину ошибки. Знать какая там "дырка в абстракции". Вполне достаточно по шагам описать свои действия, которые привели к этой ошибке. Тем более далеко не факт, что угадали верно. Мы видим только результат, а о точной причине можем лишь догадываться.

[ice]

Цитата:

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

Если Вы делаете PK на основании EDT и устанавливаете Relation, то такой пункты меню, как "Перейти к основной таблице" появляется как бы "автоматически". Вы ничего для этого специально не делаете. Вы можете ничего не знать, про факт существования такого пункта меню, но он все равно появится вне зависимости от Вашего знания.

Если Вы этого не делаете, то в случае возникновения необходимости в пункте меню "Перейти к основной таблице" необходимо будет перекрывать методы и писать код. Система "тонко намекает", что Вы делаете что-то не то. Что-то, что идет в разрез с ее идеологией.

не совсем верно. знание, что можно настроить релейшн на EDT с неба не падают, это фича системы. причем настоев EDT на новую таблицу мы не получим автоматический переход к основной таблице,поле в таблице должно быть ключем, в таблице необходимо заполнить свойство FormRef, для заполнения которого нужен MenuItem, ссылающийся на форму с той самой таблицей, причем датасорс с таблицей должен быть главным на этой форме, таким образом, все таки приестся после "А", сделать и "Б", "В" и тд

[ax_mct]

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Давайте заменим (уже) пользователя на (еще) покупателя. Или на клиента который должен оплатить эту работу. Уже выглядит немного по-другому, не так ли?

AX 7 программист будет создавать HTML5 интерфейсы. Ему действительно может быть и не нужна лишняя теория примерно так же как и и простому обывателю создающему свой личный сайт на сайте конструкторе. Некоторые из-них весьма неплохи, wix и прочие.

Но только до определенного уровня. Так как все хорошо когда "базовые" и "стандартные" потребности предусмотренные изначально. А вот мне как-то все больше AX клиенты со своими "особыми" потребностями к EP попадались, да и не только к EP. Весьма ожидаю подобные запросы и к HTML5 интерфейсу.

Очень тяжело вериться в "сказочный" успех HTML5 интерфейса если не будет возможности полностью его контролировать и соответственно модифицировать. Не на уровне "генератора" а на уровне программиста умеющего работать и с HTML, JavaScript и CSS напрямую. Не потому что хочется ложкой вместо лопаты копать, а потому что нужна и ложка и лопата. C отделением Front-End разработки от Back-End разработки.

А иначе это X++ --> XX+ (сейчас) --> XXX.

[skuull]

Цитата:

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

Очень тяжело вериться в "сказочный" успех HTML5 интерфейса если не будет возможности полностью его контролировать и соответственно модифицировать. Не на уровне "генератора" а на уровне программиста умеющего работать и с HTML, JavaScript и CSS напрямую. Не потому что хочется ложкой вместо лопаты копать, а потому что нужна и ложка и лопата. C отделением Front-End разработки от Back-End разработки.
.

А что у вас сейчас есть возможность полностью контролировать интерфейс?
В той Ах которая есть у меня есть свой конструктор который не требует от меня понимания того как он там внутри работает и вроде все счастливы, не считая тех кто пытаеться 3d модели склада с полочками рисовать, хотя даже они вроде не жалуються.

[EVGL]

Цитата:

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

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

А мне верится легко с учетом ошеломительного успеха Dynamics CRM в последние несколько лет. Интерфейс идентичен AX 7. Разумеется, успеху Dynamics CRM еще способствует стремительное развитие функционала с тактом раз в квартал.

[Logger]

Цитата:

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

А мне верится легко с учетом ошеломительного успеха Dynamics CRM в последние несколько лет. Интерфейс идентичен AX 7. Разумеется, успеху Dynamics CRM еще способствует стремительное развитие функционала с тактом раз в квартал.

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

[ax_mct]

Цитата:

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

А что у вас сейчас есть возможность полностью контролировать интерфейс?
В той Ах которая есть у меня есть свой конструктор который не требует от меня понимания того как он там внутри работает и вроде все счастливы, не считая тех кто пытаеться 3d модели склада с полочками рисовать, хотя даже они вроде не жалуються.

Desktop приложение - это один как бы application, одна среда выполнения. Одно государство.

Web приложение - это как бы два applications, две разных среды выполнения. Серверная часть это одно государство, клиентская (UI) - совсем другое, независимое.

Не нужно контролировать как работает среда выполнения в браузере но нужно полностью контролировать инструкции которые мы посылаем между двумя разными мирами.

[ax_mct]

Цитата:

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

А мне верится легко с учетом ошеломительного успеха Dynamics CRM в последние несколько лет. Интерфейс идентичен AX 7. Разумеется, успеху Dynamics CRM еще способствует стремительное развитие функционала с тактом раз в квартал.

Не о приемлимости интерфейса речь, а о приемлимости абстрагирования AX программиста от прямого программирования для HTML5 интерфейса.

То же программирование для Dynamics CRM предполагает полный контроль программиста и соответствующие знания.
https://msdn.microsoft.com/en-us/library/gg309637.aspx

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

[AP-1055D]

Цитата:

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

То же программирование для Dynamics CRM предполагает полный контроль программиста и соответствующие знания.
https://msdn.microsoft.com/en-us/library/gg309637.aspx

Я извиняюсь, не люблю спорить, но опять не могу согласиться с вами. Моё беглое знакомство с разработкой для CRM говорит о том, что полного контроля над UI у вас нет. Несмотря на то, что CRM написан на WebForms и, по сути, тот же ASP.Net, возможностей для модификации существующих форм у вас не так много. Вы не можете залезть в HTML код страницы и что-то подкрутить там. Да, вы можете добавить js или изменить глобальный CSS, но не более. При этом на js чаще всего реализуют простую бизнес-логику типа валидации или автоматического заполнения полей. К сожалению, у меня был достаточно беглый опыт знакомства с CRM, я могу ошибаться, но где-то на форуме я читал, что в CRM есть очень существенные ограничения на модификацию существующих форм. Но про "подкрутить чего-там" я уверен. Я не мог менять код. Возможно, как-то это и можно сделать, но это 100% путь самурая.

Я думаю, что в 90% случаев вам будет достаточно общего знания pure js, то есть менее 30% от знания связки HTML + js + CSS. Вполне возможно, что однажды вам понадобиться сделать те самые 10% случаев. Однако даже в этом случае вам потребуется не такие глубокие знания HTML + js + CSS (где-то 60-70%). При этом я говорю об HTML, а не об HTML5.

Вот в SharePoint вы можете делать хоть что на HTML + js + CSS :-) Тут у вас почти полный контроль, я думаю. Но SharePoint это ужас летящий на крыльях ночи, и мало кто в разумном уме и за разумные деньги захочет точить эту глыбу. Кто пробовал разрабатывать на нём что-то сложнее Hello World, тот поймёт меня. ASP.Net Next наше всё :-)

[ax_mct]

Цитата:

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

Я извиняюсь, не люблю спорить, но опять не могу согласиться с вами. Моё беглое знакомство с разработкой для CRM говорит о том, что полного контроля над UI у вас нет. ...Несмотря на то, что CRM написан на WebForms и, по сути, тот же ASP.Net, возможностей для модификации существующих форм у вас не так много.

Думаю что так и будет так как предельно логично и в стиле Microsoft. Связать нас дурачков по рукам и ногам ограничениями инструментария типа для нас же лучше.
Но это я брюзжу, накопилось просто.

А по теме вот вам навскидку требования
Microsoft Dynamics CRM Developer
http://uk.dice.com/IT-Job/Microsoft-...&source=search

--Expert JavaScript knowledge with extensive experience using JQuery
--Skilled in hand-coding XHTML and related technologies such as CSS

[AP-1055D]

Судя по описанию, требуется больше C#-разработчик, который будет заниматься в том числе Dynamics CRM. Для разработки в CRM не требуется In-depth knowledge of C# также как и Expert JavaScript knowledge. Там нет и десятой части от всего .Net.

А если у вас действительно Expert JavaScript knowledge, то этого будет более чем достаточно чтобы найти работу frontend-разработчиком без всяких там CRM, SQL Server, .Net. SSRS на рынке на два порядка большим всего рынка Dynamics с тем же или большим уровнем дохода. И работать где-нибудь в Facebook :-)

[ax_mct]

Цитата:

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

Судя по описанию, требуется больше C#-разработчик, который будет заниматься в том числе Dynamics CRM. Для разработки в CRM не требуется In-depth knowledge of C# также как и Expert JavaScript knowledge. Там нет и десятой части от всего .Net.

Да, все верно. Для работы с продуктами Microsoft не нужны глубокие знания программирования, а нужны глубокие знания этих самых продуктов.

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

Цитата:

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

А если у вас действительно Expert JavaScript knowledge, то этого будет более чем достаточно чтобы найти работу frontend-разработчиком без всяких там CRM, SQL Server, .Net. SSRS на рынке на два порядка большим всего рынка Dynamics с тем же или большим уровнем дохода. И работать где-нибудь в Facebook :-)

Променять кровавый энтерпрайз с взлетающим ugly 32GB RAM Windows лаптопом в душной и тесной каморке предприятия
на реальное программирование с элегантным MacBook 4GB RAM в современном бизнес-офисе?
Вы шутите? Чтобы оркский шаман предал свою родную степь и ушел к эльфам в волшебный лес?

[AP-1055D]

Честно, не понял о чём вы :-)

[ax_mct]

Цитата:

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

Честно, не понял о чём вы :-)

Если вы/компания/команда можете выбирать между инструментами для программирования (IDE, Frameworks), а то и наиболее подходящий язык для данного проекта, то вы можете себя называть программистом.

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

Стать свободным человеком не так и просто, рынок смотрит на ваш недавний коммерческий опыт, а не на ваше мнение о самом себе как о программисте.

[gl00mie]

Цитата:

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

Если вы/компания/команда можете выбирать между инструментами для программирования (IDE, Frameworks), а то и наиболее подходящий язык для данного проекта, то вы можете себя называть программистом.
В остальных случаях вы "специалист по обслуживанию", "техник". По сути крепостной. Который чем больше работает тем все большую зависимость получает и все больше деградирует как программист.

По-моему, если вы/компания/команда можете выбирать IDE/Frameworks/язык программирования, то обычно это говорит о том, что у вас офигенно широкий круг областей, в которых вы работает, может, от программирования встраиваемых систем до систем распределенных вычислений с веб-мордой Много ли таких людей/команд/компаний? Даже компаний-то - вряд ли много, а уж людей и команд - и подавно. Если же вы работаете в какой-то одной или нескольких смежных областях, то волей-неволей нарабатываются привычки/устои/традиции использования одной-двух IDE и определенных, зарекомендовавших себя фреймворков, в т.ч. собственной разработки. Ну, может, в качестве языков есть небольшой выбор.

Цитата:

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

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

В таком случае, веб-программисты, пишущие на PHP + JS и имеющие глубокие знания, скажем, MySQL, AngularJS и jQuery, - тоже не программисты, а "техники"? Хочется вспомнить статью Лорд Палмерстон в программировании:

Цитата:

Вы можете думать, что 90% навыков программирования составляют ваши превосходные знания C++, а различные API - это только 10%-ый пушок, в котором вы сможете разобраться за несколько недель. Этим людям я скромно подсказываю: времена изменились. Соотношение изменилось на противоположное. Очень немного людей работает над низкоуровневыми алгоритмами на C, которые только перемещают байты и не более того. Большинство из нас проводит все наше время эти дни, вызывая различные API, а, вовсе не перемещая байты. Каким бы превосходным C++ кодировщиком ни был человек, без опыта в API он знает только около 10% того, что он должен использовать каждый день для написания кода, запускаемого на API. Когда дела в экономике идут хорошо, это не имеет значения. Вы все еще имеете работу и наниматели платят стоимость вашего обучения соответствующей платформе. Но когда в экономике царит неразбериха и 600 человек подают заявления на каждую открытую вакансию, наниматели могут позволить себе удовольствие выбирать программистов которые уже эксперты в интересующей их области.
Что лучше XUL, Eclipse's SWT, или wxWindows? Я не знаю. Все они - настолько большие области, что я не могу по-настоящему попробовать их и сказать. Не достаточно просто прочитать описание. Вы должны кровью и потом проработать с этими приложением год или два, перед тем как вы узнаете, что оно достаточно хорошо, либо поймете, что не имеет значения все ваши старания, вы не сможете придать вашему графическому интерфейсу вкус настоящей еды. К несчастью, для большинства проектов вы должны решить, какую область программирования вы будете использовать, перед тем как напишите первую строчку кода, а это уж точно момент, когда вы имеете меньше всего информации.
Таким образом, теперь, мой совет следующий. Не начинайте нового проекта без как минимум одного архитектора программного обеспечения с несколькими годами реального опыта в языке, классах, различных API и платформах, под которые вы строите приложение. Если у вас есть выбор платформ, используйте ту в написании кода, для которой ваша команда имеет больше опыта, даже если она и не самая модная и номинально не самая продуктивная.

[ax_mct]

Да, в реальности такая свобода инструментов редкость. Но тогда перефразирую на способность и независимость самого программиста от таких инструментов, хотя бы в воображении Когда использование того же Notepad++ для .NET разработки не вызывает обморока. То есть нелепо, но возможно. Текстовые файлы, командная строка.

Веб-программисты на том же PHP они на самом деле больше программисты чем мы. Именно потому что их опыт более независим от инструментов. Замена одного IDE на другое - вопрос лишь комфорта. Framework - в зависимости от проекта.

А теперь уберем от типичного корпоративного программиста Visual Studio. Дадим ему тот же Eclipse c плагином для C sharp. Тут уже будет не вопрос комфорта, а в морду тому кто убрал Visual Studio. Зависимость и неуверенность.

Цитата:

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

Выделенное это тупик. Писать окна на C++ MFC вместо VB, использовать VB вместо С++ на ресурсных участках, применять ООП и Windows events в web и т.д. это как бензопилой резать хлеб и столовым ножом резать дерево.

Негодный инструментарий дорого обходится. Взять тот же e-Commerce web сайт в AX Retail. Все так же как и в EP. Web-parts, Sharepoint 2013. С другими инструментами можно сделать то же самое намного эффективнее и дешевле и красивее. А так все просто золотое получается. И как золотарь я только рад Но как программист я в недоумении...